Relationship between pugs and parrot/language/perl6
I see that there's work being done on a perl6 implementation under languages in parrot. How is this effort related to the pugs project? Is the aim of this to provide an alternative implementation of perl6 to pugs? Is one of them the destined to be the canonical implementation, or is there going to be such a thing? BTW, glad to see the emergence of this mailing list, but I noticed it not yet listed on the "Current mailinglists" page here: http:// dev.perl.org/perl6/lists/.
Re: Perl6 perlplexities [was: "Re: $1 change issues..."]
> Okay, I won't shout (not even on PerlMonks :-), but named parameters
> default to optional, so you'd have to write that as
>
> sub convert (:$from!, :$to!, :$thing!) { ... }
>
> in the current scheme of things.
Either way, the point is still that the benefits FAR outweigh any
additional complexity. Ruby could benefit from this, too. (While
first-class blocks rock my world, the weird subroutine signature stuff
most certainly doesn't.)
Rob
Sometimes MakeMaker won't make.
I've had this problem for awhile with a distribution I've been working on where sometimes, after invoking Makefile.PL, typing 'make' creates a blib folder with all of the .exists files in the right places, but doesn't copy the actual module files to it. This was driving me crazy. I don't have a solution. In desperation I removed everything from the folder that wasn't bundled with 'make tardist', cleaned it, and ran Makefile.PL again... and no love. but then suddenly thru nothing I could figure out, it started working again. Does this sound like a pretty half-assed problem? I thought so too. I figured it's my fault, don't bug other people for my mistakes. Well, last week I went to go write a little experimental module for myself, Tree::Splay (Hi Schwern!). I created Tree/Splay.pm Tree/Splay/Node.pm Tree/Splay/IntRange.pm t/01_basics.t t/02_compat.t Makefile.PL MANIFEST Makefile.PL contains: ===bof=== use ExtUtils::MakeMaker; WriteMakefile( NAME=> 'Tree::Splay', VERSION_FROM=> 'Tree/Splay.pm' ); ===eof=== and when I run Makefile.PL and then make, I get the same damn thing: blib gets created with .exists files, and pm_to_blib is touched, but *nothing* else happens. So I thought to myself, maybe it doesn't like its environment. So I removed *EVERY* *SINGLE* file and subdirectory from the subdir where I was working except what I named above and the *~ backup files that emacs creates. Still no luck. I type make, I get pm_to_blib and blib/* skeleton but my files don't get copied into blib. Since I don't think I'm stupid, but I'm willing to admit ignorance: WTF??? What did I miss here?? TIA! L8r, Rob
Re: Sometimes MakeMaker won't make.
Adam Kennedy wrote: > Doesn't makemaker only like you if you have a single .pm file just in > the root directory? > > And otherwise you have to have your lib files actually under lib? > > lib/Tree/Splay.pm > lib/Tree/Splay/Node.pm > lib/Tree/Splay/IntRange.pm > t/01_basics.t > t/02_compat.t > Makefile.PL > MANIFEST > > - > > use ExtUtils::MakeMaker; > > WriteMakefile( > NAME=> 'Tree::Splay', > VERSION_FROM=> 'lib/Tree/Splay.pm' > ); > > Try that... Well... I don't know if your conjecture is true, but your suggestion worked like a charm. Thanks! (and now I'm on my way to reorganize my other distribution...) L8r, Rob
Re: Implicit Role Declarations (was Re: implicitly doing a role)
On 11/8/05, chromatic <[EMAIL PROTECTED]> wrote: > On Fri, 2005-11-04 at 13:15 -0500, Austin Frank wrote: > > > If roles are interfaces, do we want any class that provides an interface > > consistent with a role to implicitly do the role? That is, if a class > > fulfills all of the interface requirements of a role without actually > > saying it does the role, does it do the role anyway? > > After thinking about this a little more, I think there may be a bit of > misunderstanding about what I want here. > > Having a class implicitly *do* a role if it has methods and attributes > of the appropriate name is a bad idea -- there's too much room for > accidental collision there. > > Sure, people shiny-eyed about duck typing might reasonably say "Why? > That doesn't make sense!" but it's a careless duck typer who randomly > throws objects in collections and hopes for the best. You *can* > mistakenly use an object that quacks incorrectly and spend some time > debugging it, but if we're providing a system that can catch some of > that incorrectness, I don't see what benefit there is to subverting its > ability to detect incorrectness. > > What I want instead, and what might seem similar in the sense that it's > exactly the opposite, is implicit declaration of a role for each > explicitly declared class. > > That is, if I declare a Dog class, there immediately springs into being > a Dog role empty of everything but the expectation that whatever does > that role provides everything publicly accessible that an instance of > the Dog class does. In other words, a role is just a closed class and a class is just an open role? Larry stipulated this about a month ago. Rob
Re: given too little
> But if we have a mandatory type inferencer underneath that is merely > ignored when it's inconvenient, then we could probably automatically > delay evaluation of the code. . . . I'm not so certain that ignoring the mandatory type inferencer is a good idea, even when it's inconvenient. I don't know about you, but my son keeps trying to get me to let him ignore his homework when it's inconvenient (ie, the gamecube calls) and I don't let him. So, just because the gamecube is calling, we should probably listen to the mandatory type inferencer.
Re: What's the latest on Iterators?
On 11/11/05, Joe Gottman <[EMAIL PROTECTED]> wrote:
>The various synopses contain many mentions of Iterators. These are used,
> for instance, to implement lazy lists so the expression 1..1_000_000 does
> not have to allocate a million element array. But as far as I can tell the
> term is never defined anywhere in the synopses. Is Iterator a role, and if
> so what methods is it required to have? Do functions like map and grep,
> which in Perl5 return lists, return Iterators in Perl6? Can an Iterator be
> passed to a function (like map and grep again) that requires a list as an
> input? Does an array or hash have only one Iterator or can it have several
> independent ones?
I'm going to speculate on a few of these items.
Iterator most certainly will be a role, though that doesn't mean that
internal iterators will do this role. I expect they would, though. It
will probably have methods that do the following:
* next_item
* prev_item
* nth_item
* rewind
* has_next_item?
* has_prev_item?
I expect that lists will be convertable to iterators and vice-versa.
You can do this in P5 already:
sub create_iterator_from_list {
my @list = @_;
return sub {
return shift @list;
};
}
create_list_from_iterator {
my ($iterator) = @_;
my @list;
while ( my $item =$iterator->() ) {
push @list, $item;
}
return @list;
}
Of course, that's extremely inefficient. I expect that Perl6 will be a
little smarter, though it's not clear how much smarter it can be. For
one thing, Iterators will have to support two modes - one where the
list is frozen (the P5 version I posted above) so that changes to list
don't change the iterator and another where the iterator iterates into
the list as it stands, so that changes to the list are reflected in
the iterator immediately. The second mode has the possibility of being
unstable, but if you choose this mode (which wouldn't be the default),
then it's on your head.
As for multiple iterators, that's the point of having a separate
iterator object. Each iterator maintains its own state, allowing for
multiple traversals across the same set.
As for lazylists (1..Inf), they have to be implemented via iterators
(which is why I'm almost positive the two will be interchangeable).
And, if you pass (1..Inf) to map/grep/sort, it would HAVE to return an
iterator back, otherwise you'll hang at that instruction.
Of course, if you said "while (my $n = 1..Inf) { }", it's on your head
to provide a "last" in there somewhere.
Rob
Re: Thoughs on Theory.pm
On 10/13/05, Dave Whipp <[EMAIL PROTECTED]> wrote:
> (ref: http://svn.openfoundry.org/pugs/docs/notes/theory.pod)
>
> >theory Ring{::R} {
> >multi infix:<+> (R, R --> R) {...}
> >multi prefix:<-> (R --> R){...}
> >multi infix:<-> (R $x, R $y --> R) { $x + (-$y) }
> >multi infix:<*> (R, R --> R) {...}
> ># only technically required to handle 0 and 1
> >multi coerce: (Int --> R) {...}
> >}
> >
> > This says that in order for a type R to be a ring, it must
> > supply these operations. The operations are necessary but
> > not sufficient to be a ring; you also have to obey some
> > algebraic laws (which are, in general, unverifiable
> > programmatically), for instance, associativity over
> > addition: C<(a + b) + c == a + (b + c)>.
>
> I started thinking about the "in general, unverifiable programmatically"
> bit. While obviously true, perhaps we can get closer than just leaving
> them as comments. It should be possible to associate a
> unit-test-generator with the theory, so I can say:
I've been thinking about this. If we have a type inferencer, we know
that any function we define to be N,N->N will be that way. The only
items we have to show is for all a in N, there is a unique succesor
which is also in N and that for all b in N, b != 1, there is a unique
predecessor. If we have that, then we get the laws of arithmetic. Is
it possible to put that into the type inferencer if the types are
defined as iterators? Kind of like Church numbers, but in P6 notation.
I think that by defining our types as iterators, we can satisfy the
succ/pred requirements of Peano's, meaning we have the arithmetic
rules.
Rob
Re: lvalue reverse and array views
On 11/20/05, Daniel Brockman <[EMAIL PROTECTED]> wrote: > Reversing an array, changing it, and then rereversing it --- > I think that kind of pattern is common. I would think that reversing a string, modifying it, then reversing it back is more common. Does modifying the reversal of a string modify the original? Rob
statement_control() (was Re: lvalue reverse and array views)
On 11/20/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
[snip]
> Yep. Also note that "for" is not a special magical construct in Perl 6,
> it's a simple subroutine (&statement_control:, with the signature
> ([EMAIL PROTECTED], Code *&code)). (Of course, it'll usually be optimized.)
>
> Example:
>
> {
> my sub statement_control: ([EMAIL PROTECTED], Code *&code) {
> map &code, reverse @array;
> }
>
> for -> $item { say $item }
> # "c\nb\na\n"
> }
>
> # for restored, as the modified for went out of scope:
> for -> $item { say $item }
> # "a\nb\nc\n"
Is there a list of the statement control items that are implemented as
such vs. implemented in another way?
Thanks,
Rob
Re: statement_control() (was Re: lvalue reverse and array views)
On 11/21/05, TSa <[EMAIL PROTECTED]> wrote:
> HaloO,
>
> Luke Palmer wrote:
> > On 11/21/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> >
> >>Of course, the compiler is free to optimize these things if it can prove
> >>that runtime's &statement_control: is the same as the internal
> >>optimized &statement_control:.
> >
> >
> > Which it definitely can't without some pragma.
>
> Isn't the question just 'when'? I think at the latest it could be
> optimized JIT before the first execution, or so. The relevant AST
> branch stays for later eval calls which in turn branch off the
> sourrounding module's version from within the running system such
> that the scope calling the eval sees the new version. And this in
> turn might be optimzed and found unchanged in its optimized form.
>
> Sort of code morphing of really first class code. Everything else
> makes closures second class ;)
This is very close to a proposal I made to the ruby-dev mailing list
(which was Warnocked). I proposed a very basic engine that would work
with the parser/lexer to determine what action to take instead of
using the huge case statements that are the heart of both P5 and Ruby.
It would look something like:
TOKEN:
while ( my $token = get_next_token() ) {
for my $length ( reverse length($token) .. 1 ) {
if ( my $actions = find_actions( substr( $token, 0, $length ) ) ) {
$action->[-1]->( < params, if necessary > );
}
next TOKEN;
}
throw SyntaxError;
}
The for-loop + substr() would be to handle longest-token-first rules.
So, "..." is correctly recognized instead of handled as ".." and ".".
The key would be that the $actions arrayref would get push'ed/pop'ed
as you enter/leave a given lexical scope.
Obviously, this could be optimized to an extremely large degree, but
it -should- work.
Rob
Re: type sigils redux, and new unary ^ operator
On 11/22/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> What tipped me over the edge, however, is that I want ^$x back for a
> unary operator that is short for 0..^$x, that is, the range from 0
> to $x - 1. I kept wanting such an operator in revising S09. It also
> makes it easy to write
>
> for ^5 { say } # 0, 1, 2, 3, 4
I read this and I'm trying to figure out why P6 needs a unary operator
for something that is an additional character written the more legible
way. To me, ^ indicates XOR, so unary ^ should really be the bit-flip
of the operand. So, ^0 would be -1 (under 2's complement) and ^1 would
be -2. I'm not sure where this would be useful, but that's what comes
to mind when discussing a unary ^.
Thanks,
Rob
Re: type sigils redux, and new unary ^ operator
On 11/23/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> On 11/23/05, Rob Kinyon <[EMAIL PROTECTED]> wrote:
> > On 11/22/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> > >
> > > for ^5 { say } # 0, 1, 2, 3, 4
> >
> > I read this and I'm trying to figure out why P6 needs a unary operator
> > for something that is an additional character written the more legible
> > way.
>
> Huh? Are you saying that 0..^5 is one more character than ^5?
No, I'm saying that 0..$n-1 is one more character than 0..^$n. And, it
has the added benefit of being legible to people who don't know the
ins and outs of every single operator of the 60+ P6 looks like it will
have.
> In any case, I'm not sure that this unary helps readability, or that I
> like it all that much, but I can say that it's damned useful. I use
> ranges of the form 0..$n-1 more than any other range, by a very long
> shot.
I don't use 0..$n-1 very often. I use 0..$#arr most often. But,
frankly, I don't use ranges very much at all. I try to avoid parallel
arrays, which is really the only time I can see using a range like
that. I try and let the datastructure (IO handle, array, etc) control
when it's done.
> > To me, ^ indicates XOR, so unary ^ should really be the bit-flip
> > of the operand.
>
> Except in Perl 6, XOR is spelled +^ or ~^, and ^ is Junctive one().
> So it seems that ^$x should be one($x). But that's an entirely
> useless, trivial junction, so it makes sense to steal the syntax for
> something else.
Here's an issue - if ^$x would be one($x), then what will [EMAIL PROTECTED] be?
To
me, that seems like it should be one(@x), which is entirely useful.
Except, if I try and use it as [EMAIL PROTECTED] (which, to me, would be
useful).
So, now, is it 0..one(@x) or [EMAIL PROTECTED]
Rob
Re: Lazy lists in Str context
On 11/23/05, Flavio S. Glock <[EMAIL PROTECTED]> wrote: > Can we have: > > say 1..Inf; > > to output an infinite stream, instead of just looping forever? > > OTOH, it would be nice if > > say substr( ~(1..Inf), 0, 10 ) > > printed "1 2 3 4 5". > > Flattened lists would still loop forever (or fail): > > say **(1..Inf); > > $s = substr( ~( **(1..Inf) ), 0, 10 ); This would work, I think, if ranges were convertable to iterators, stringification was lazy, and substr() informed the stringification of how much it needed to do. I'm not sure how feasible that last one is ... Rob
Re: Lazy lists in Str context
On 11/23/05, Flavio S. Glock <[EMAIL PROTECTED]> wrote:
> How about allowing reduce() to return a scalar with the same laziness
> as the list:
>
> [EMAIL PROTECTED] - a lazy string if @list is lazy
> [EMAIL PROTECTED] - a lazy number if @list is lazy
>
> It would look like:
>
> $foo = substr( [~](1..Inf), 10 );
> my $revfoo := reverse $foo;
> $revfoo ~~ s/foo/bar/g;
That would violate the principle of least surprise. If all scalars
are, by default, eager, then:
foo( [EMAIL PROTECTED] );
foo( @list.join('') );
could potentially do different things, including possibly run out of
memory in some cases. Plus, what if the @list isn't lazy?
Better, I think, would be:
say substr( ~(1..Inf) is lazy, 0, 10 );
Or, have substr()'s signature be:
sub substr( Str $str is rw is lazy, Int $start, Int $?end, Int $?replacement );
Rob
Re: type sigils redux, and new unary ^ operator
On 11/23/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> : I'm also puzzled that you feel the need to write 0..$n-1 so often; there
> : are so many alternatives to fenceposting in P5 that I almost never write
> : an expression like that, so why is it cropping up that much in P6?
>
> Couple reasons occur to me offhand. First we're doing away with $#foo.
> Second is all the array sizing in P5 is implicit, whereas S9 style
> arrays are all about explicit array sizing, and 0..$n-1 comes up all
> the time there. But I also am liking the generalization of unary ^
> to mean domain.
What about @array.indices instead? Then, there's no possible
fenceposting, your code is self-documenting, and we're not introducing
another unary operator?
> And in an axiomatic sort of way, it corresponds to those theories
> of math that build up the integers by counting set elements. The
> "argument" that produces 5 is 0..4. And it works out that +^5 == 5.
So, +^5 is the way to generate the Church number for 5 through the use
of an iterator masquerading as a range?
> But the generalization to hashes is even cooler because I can say
>
> my %thishash{^%thathash};
>
> or some such to duplicate the "shape" regardless of the typology
> of %thathash.
my %thishash{%thathash.keys};
Much easier to read. The methods are there for a reason. Don't re-add
operators where there's a perfectly good method. Plus, overwriting
methods is much easier to grok for the average programmer than the
corresponding operator, unless you're aliasing the operator, in which
case I have problems figuring out why this is good, unless we're
deliberately designing P6 for the obfu/golf crowd.
Capabilities in Perl6?
I just read the slides about CAPerl (http://caperl.links.org/) and it's an interesting idea. Leaving aside the question of whether this would work in Perl5 or not, I think it would be very interesting to look at building this concept into Perl6. Here's how I'd envision doing so: * Any subroutine is allowed to work with the parameters it was given. (If you didn't want it to work with those, why did you give them to it?) Variables outside its scope are, by default, not allowed. * When looking at a variable you're allowed to see, you are only allowed to use the methods it exposes - no peeking! * A subroutine may be explicitly granted access to a variable in a parent scope through the "grant" keyword. (More later.) * A subroutine may be disallowed access to a variable in a parent scope through the "revoke" keyword. (More later.) * Access to resources outside the program (files, etc) must be provided to the subroutine through parameters or explicit grants. * The outermost scope is completely trusted. (Someone has to be ...) Grant/revoke (names may be changed, as needed) take the following (pseudocode) signatures: grant ( Sub, Var, [Var, ... ] ) revoke( Sub, Var, [Var, ... ] ) It is an error to: * attempt to grant/revoke access to a variable you don't have access to * attempt to grant/revoke access to a variable that isn't in scope for the grantee Thanks, Rob
Re: Perl grammar for Perl5 -> Perl6
> As for the original question, I think that the Perl 6 grammar will > be a much better example for how to parse other languages than a > Perl 5 grammar would be, since one of the underlying design currents > from the beginning has been that Perl 6 had to be a language that > was amenable to parsing by Perl 6 rules (with a little help from a > bottom-up operator-precedence expression parser.) Once Patrick is done with PGE, will it be able to parse Perl5? If so, why aren't we focusing on that? Rob
Re: Modular versions and APIs
On 12/8/05, Larry Wall <[EMAIL PROTECTED]> wrote: > [snip] Certainly, as you speculate, if different authors want > to share an API, they can give it an "API" author that knows how to > delegate to one of the authors. Would you mind elaborating on this some more? Thanks, Rob
Re: relational data models and Perl 6
[snip entire conversation so far] (Please bear with me - I'm going to go in random directions.) Someone please correct me if I'm wrong, but it seems that there's only a few things missing in P6: 1) An elegant way of creating a tuple-type (the "table", so to speak) 2) A way of providing constraints across the actual tuples of a given tuple-type 3) Syntactic sugar for performing the relational calculus To me, a tuple-type is more than a class in the standard OO. It has to be able to apply any constraints that might be upon the tuple-type, such as uniqueness of a given element across all tuples or foreign-key constraints. While this is certainly possible using the P6 OO constructs, it would make sense for a baseclass to provide this functionality. Actually, this is a really great place for metaclasses to shine. The actual tuple-type needs to be constructed from some class-constructor (which would be, in the metamodel, itself a class). This is so that it has the appropriate types for the elements of the tuple along with any necessary constraints upon the tuples / elements of the tuples. In addition, you're going to want to take actions not just on the tuple, but on the entire tuple-type. That screams class-level methods that operate across all instances of the class. Maybe, a set of roles would be good for organizing this kind of across-all-instances behavior that the tuple-type can take advantage of. I'm sure that this wouldn't be limited to just the relational calculus. As for the syntactic sugar, I'm not quite sure what should be done here. And, with macros, it's not clear that there needs to be an authoritative answer. Personally, I'd simply overload + for union, - for difference, * for cross-product, / for divide, and so forth. There's been some discussion with sets as to creating new operators using the set-operators that come in Unicode. As tuples and relations among tuples aren't necessarily sets, those might not be appropriate. It also seems clear that junctionish iterators may be of use here. For example, "Give me all the tuples that match this criteria" might return an iterator that also acts as an any-junction. It could also return a class object that has a different set of instances marked as created from it. Though, I'm not too sure how that would work when asking a given instance "who is the class object that created you?" ... maybe it returns the initial one or maybe it returns them all? I think the initial one is more correct, as the others are just subsets. When dealing with SQL, I don't care about the subsets that a given row belongs to - I only care about the table. So, maybe the subset class objects delegate all methods to the original class object except for those that deal with "Who do you have?" and "Give me a subset where ..." Also, joins between tuple-types would have to create a new tuple-type, with the tuples within being delegators to the underlying tuples? I'm not sure that this (or any other) derived tuple-type class object should be allowed to create new tuples (though I'm sure someone can think of a good reason why I'm wrong). Again, just a bunch of meandering thoughts. Bonus points to whomever can help me bridge the gap between what I just blathered and an elegant solution to Sudoku. Rob
Re: relational data models and Perl 6
On 12/16/05, Ovid <[EMAIL PROTECTED]> wrote: > --- Rob Kinyon <[EMAIL PROTECTED]> wrote: > > > As for the syntactic sugar, I'm not quite sure what should be > > done here. And, with macros, it's not clear that there needs > > to be an authoritative answer. Personally, I'd simply overload > > + for union, - for difference, * for cross-product, / for > > divide, and so forth. > > Bear with me for just a moment here while I provide some background. > I'll eventually touch on Rob's topic. > > One of the issues with handling relations correctly in databases is the > following: > > SELECT emp.name, cust.balance > FROM emp, cust > WHERE emp.id = cust.age > > That's perfectly valid SQL but it doesn't make a lick of sense. In the > original relational model, that would not be a valid query because the > emp.id would be a different type from the cust.age. Operations between > different types are simply not allowed. > > However, sometimes it makes sense to allow those operations, though. > For example, if cust.id and emp.id are different types but may share > identical and meaningful integer values, you might want to compare > those even though you can't. So every type must have "selectors" which > behave more or less like we think of when we try to cast a variable to > a different type. > > So what if, for some crazy reason, we really did want to compare emp.id > to cust.age. If cust.age is an integer, we might have something like > this pseudo-code: > > WHERE emp.id = EMP_ID(cust.age) I'm going to interject here with the following: * P6 has the capability to be optionally strongly-typed. This is obvious from the type signatures, if nothing else. * According to the latest metamodel, as I understand it from Stevan, types are, essentially, classes. This implies that I can create my own types that inherit from some base type. Overriding the operators in a generic way so that you have to have an exact type match before you compare values also, imho, shouldn't be that hard. So, for the relational calculus, you can have very strong typing. > * The domain of acceptable values (potentially infinite) > * Selectors to cast to and from the value > * Operators and their behaviors I would argue that you don't have selectors, by default. You should have to explicitly add a selector. Otherwise, into C-land you will go, my son! > Needless to say, in order to properly apply the relational model, we > wind up with mandatory strong typing and this takes us very far afield > from Perl. If we skip the strong typing, we may still have something > good, but it won't be the relational model. If you end up in the relational section, which will be invoked with a module, then you are choosing to use the typing that is available through that module. I don't think anyone has argued that the relational model should be built into the core or should even be a module included in the core. In fact, I see at least three modules coming out of this - Type::Create, Type::Strengthen, and Model::Relational. Of these, I would think only the Type:: modules should even have a chance to be in the core distro. Type::Create may be a consequence of the metamodel, but I'll let Steve or Audrey field that one. Rob
Re: relational data models and Perl 6
On 12/16/05, Ovid <[EMAIL PROTECTED]> wrote: > Minor nit: we're discussing to the relational algebra and not the > relational Calculus (unless the topic changed and I wasn't paying > attention. I wouldn't be surprised :) Algebra, in general, is a specific form of calculus. So, we're speaking of the same thing, just in different terms. > > > * The domain of acceptable values (potentially infinite) > > > * Selectors to cast to and from the value > > > * Operators and their behaviors > > > > I would argue that you don't have selectors, by default. You > > should have to explicitly add a selector. Otherwise, into > > C-land you will go, my son! > > I'm not entirely sure, but I think we agree here. You have to have, at > minimum, one selector for each new datatype if for no other reason than > to cast a string to your new data type. Otherwise, your data types > would only be constants because you would have no way of assigning a > value. Fair enough. One would need to be able to convert back and forth between the base type (Int, String, etc) and the type. Rob
Re: handling undef better
On 12/16/05, Darren Duncan <[EMAIL PROTECTED]> wrote: > Something else I've been thinking about, as a tangent to the > relational data models discussion, concerns Perl's concept of > "undef", which I see as being fully equivalent to the relational > model's concept of "null". The relational model doesn't have a concept of NULL. SQL has a concept of NULL which many relational theorists feel is completely bad. The way to look at NULL is as a CodeSmell saying "I haven't normalized this data enough." > Therefore, I propose that the default behaviour of Perl 6 be changed > or maintained such that: > > 0. An undefined value should never magically change into a defined > value, at least by default. Fold this into strictures. Instead of this, there should be a stricture for it. "use strict 'undef';" sounds nice. > 1. Any expression that expects a defined value as an argument, such > as typical mathematical or string operations, and gets an undefined > argument, will as a whole have undef as its value, or it will fail. > Examples are the expressions "$anything + undef" and "$anything ~ > undef". > > 1a. If such an expression will always return a value, the value is undef. > > 1b. If the expression is allowed to fail, it can do that instead. I'm not sure I want to see the NaN fallacy in Perl6. Since every operation is allowed to fail through throwing an exception, I'd argue that this should be the case under strict 'undef'. > 2. Any boolean-returning expression should return undef or false or > fail if given an undef. > > 2a. At the very least, "undef undef" should NEVER > return true, because an unknown quantity can not be claimed to be > equal to an unknown quantity. Rather, the defined() method, which is > analagous to 'IS NOT NULL', and such things are the proper way to > test if a variable is unknown. > > 2b. As a pseudo-exception, while undef/unknown values are > conceptually all unequal to each other, they should all sort > together; eg, calling sort() on an array of values where some are > defined and some not, should group all the undefs together. I leave > it up to discussion as to whether they should sort before or after > all the defined values, but one of those choices should be picked for > predictability. How many different undefs are there? [snip] > The fact is, that in any normal program, using an undefined value as > if it were a defined one is a bug. . . . Many times, I've treated undef as 0 or '' in little scripty-doos, simply because it's easier to do it that way. I think that this behavior (which is desirable) and the behavior you're describing (which is desirable) is easily handled by a new stricture. > Now, in the spirit of TMTOWTDI, such as for people that like to turn > strictures or warnings off, I suggest that there can be an optional > feature, perhaps a pragma or better a core module, where a developer > can say that they want undefs to automatically become zero in numeric > contexts or an empty string in string contexts, or false in boolean > contexts, etc. But they should have to explicitly activate that > feature, like saying "treat undef as 0 in all my code", and this > treating would not happen by default. No - a stricture. :-) Rob
Re: handling undef better
On 12/17/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
[snip]
> 2. Until a value is put in a container, the container has the
> POTENTIAL to store any value from its domain, so with respect to that
> container, there are as many undefs as there are values in its
> domain; with some container types, this is an infinite number.
>
> Only a container that can have exactly one possible value can be
> equated with; but then you have a constant.
>
> In a manner of speaking, an undef is like a quantum superposition, in
> that it has no specified value, but rather all possible domain values
> at once, so you can not absolutely say it is equal to anything.
So, in essence, you're saying that undef === one( #the domain of the
type# ) ... I'm not sure I'm comfortable with that. If I have an undef
of a constrained type and I compare it to a value of some other
constrained type whose domains don't overlap, then, by this
definition, I -can- say something about the truth value. For example,
if I define EvenInt and OddInt in the obvious ways, then the following
should hold:
my EvenInt $e;
my OddInt $o;
if ( $e != $o ) { say "This should print out." }
I'm not sure that works with the Principle of Least Surprise. While I
cannot say what it is, you're saying that I can now say what it isn't.
While that follows from typing, that doesn't follow from the common
understanding of undef.
Rob
Re: Iterating over complex structures
On 12/22/05, Michele Dondi <[EMAIL PROTECTED]> wrote: > Suppose I want to navigate a tree and print out info contained in each of > its leaves along with info gathered from the position in the tree of the > list itself? Can I do it in a "universal" manner as hinted above that > would work for other situations as well? In Ruby, each collection class that wishes to be iterated over mixes in the Enumerable class. In a crude way, you can almost use that as the definition of what makes an class a collection. All the class has to provide is each(), which is a method that, according to the Ruby book, "yields successive members of the collection." If the class wishes to use the sorting items, then it has to provide a meaningful spaceship operator. each() (and a number of other methods) then takes a block that it executes at every node. As everything in Perl6 will be an object, I think we should be looking at Ruby for possible solutions to this kind of problem. The Ruby way, imho, would be to provide a set of "each()" methods that you can choose to use, depending on how you wanted to iterate over the object. The each() method you choose could maintain some kind of state about where the element is in the collection. Or, and this would be my preference, the elements should have the ability to return that state when queried. This implication here is that there should be an Enumerable role (or set of roles) in Perl6 that provides this kind of capability. In addition, there should probably be a useful set of base classes to do things like Set, Bag, Tree, etc. Then, if I wanted to create a 3-2 tree which only takes values that is-a Floober and default to iterating over it in level-order, I can do that in less than 20 lines of code within a class. Then, I use that class when I want to use my arbitrary data structure. The further implication of this is that I don't think we will be using AoHoAoHo... in applications anymore. In 1-off scripts, sure! But, we'll have the infrastructure to create usable classes that abstract away 90% of the complexity of our data structures, allowing us to focus on the similarities in our code vs. the differences. Ruby takes duck-typing to a religious mantra, which can be annoying, but it's definitely very productive. Perl6 could do worse than copying that to a large degree. Of course, this doesn't work for arbitrary complex structures, but I don't think anything would work for those. Rob
Re: Array/list transformations.
On 12/22/05, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote: > On Thu, Dec 22, 2005 at 04:47:21PM +0100, Michele Dondi wrote: > > Also I wonder if one will be able to push(), pop(), etc. array slices as > > well whole arrays. A' la > > > > my @a=qw/aa bb cc dd ee/; > > my $s=pop @a[0..2]; # or [0,2] or just [0] for that matters! > > # $s='cc'; > > # @a=qw/aa bb dd ee/; => same as what I can do with slice() > > > > Not terribly necessary, but indeed consistent IMHO. > > Not quite sure why you'd want this, but if we have something like this: > > my @a = qw/aa bb cc dd ee/; > my @slice := @a[0..2]; > my $s = pop @slice; > > (where @slice is a "reference" to part of @a) > > You get what you want and more. To echo Scott's point, @a[0..2] === @a.splice(0,3). Now, a more interesting problem is @a[0,2,4], which doesn't map to a single splice() call. Ruby's syntax for this is problematic, which points to a problem with how the solutionspaces are mapping to the problemspaces. Creating an array whose positions are aliases for positions in another array can be useful. How about my @s := @a[0,2,4] is alias; @a[2] = 3; # @s[1] == 3 @s[1] = 4; # @a[2] == 4 The default slicing behavior would default to "is copy", to preserve the current semantics. Does that sound reasonable? Rob
Re: Array/list transformations.
On 12/27/05, Larry Wall <[EMAIL PROTECTED]> wrote: > On Tue, Dec 27, 2005 at 12:10:45AM -0500, Rob Kinyon wrote: > : Creating an array whose positions are aliases for positions in another > : array can be useful. How about > : > : my @s := @a[0,2,4] is alias; > : > : @a[2] = 3; # @s[1] == 3 > : @s[1] = 4; # @a[2] == 4 > : > : The default slicing behavior would default to "is copy", to preserve > : the current semantics. Does that sound reasonable? > > Hmm. Assignment is already adequate for copying semantics. And binding > the individual elements can presumably be done by: > > my [EMAIL PROTECTED] := @a[0,2,4]; What's the difference between: my @s := @a[0,2,4]; and my [EMAIL PROTECTED] := @a[0,2,4]; ? Rob
Re: relationship between slurpy parameters and named args?
On 12/30/05, Piers Cawley <[EMAIL PROTECTED]> wrote: > Stuart Cook <[EMAIL PROTECTED]> writes: > > > On 29/12/05, Austin Frank <[EMAIL PROTECTED]> wrote: > >> So, is there a conceptual connection between imposing named argument > >> interpretation on pairs in an arg list and slurping up the end of a > >> parameter list? Are there other meanings of prefix:<*> that relate to > >> one or the other of these two meanings? > > > > The missing link is that prefix:<*> in an argument list also causes > > things like arrays to be treated as a sequence of separate parameters, > > rather than as a single array parameter. See "Flattening argument > > lists" in S06. > > > > (This was the original meaning of prefix:<*> in arglists; the > > named-pair behaviour was added later, when pair values ceased to have > > named behaviour automatically.) > > Personally, I think that prefix * in an arglist should only flatten > array arguments if there is only one array. And if it doesn't, how do > I declare parameter that is 'a slurpy list of arrays' or 'the rest > of the arguments, without flattening'. If I *really* want aggressive > flattening then I can call, say, @slurpy_param.flatten Does this imply that [EMAIL PROTECTED] === @slurpy.flatten ? Or, put another way, can't we just say that prefixed * is symbolic notation for flatten() in the same way that postfixed [] is symbolic notation for slice()? Rob
Re: Junctions again (was Re: binding arguments)
On 1/2/06, TSa <[EMAIL PROTECTED]> wrote:
> HaloO,
>
> Luke Palmer wrote:
> > The point was that you should know when you're passing a named
> > argument, always. Objects that behave specially when passed to a
> > function prevent the ability to abstract uniformly using functions.[1]
> > ...
> > [1] This is one of my quibbles with junctions, too.
>
> You mean the fact that after $junc = any(1,2,3) there is
> no syntactical indication of non-scalar magic in subsequent
> uses of $junc e.g. when subs are auto-threaded? I strongly
> agree. But I'm striving for a definition where the predicate
> nature of the junctions is obvious and the magic under control
> of the type system.
I'm confused at the confusion. To me, junctions are just magical
values, not magical scalars. In theory, one should be able to create
junctions of arrays, hashes, or subs just as easily.
my @junc = any( @a, @b, @c );
my %junc = any( %a, %b, %c );
Then,
if @junc[2] == 9 { ... }
would imply
if @a[2] == 9 || @b[2] == 9 || @c[2] == 9 { ... }
IMHO, one thing that may be causing issues with the junction concept
is that I've never seen anyone talk about the implicit read-only
behavior of a junction. To me, a junction would be required to be
read-only (except for overall assignment). To modify the junction
would be to overwrite it. So, given
my $junc = any( $a, $b, $c );
If you wanted to add $d into there, you'd have to do it this way:
$junc = any( $junc, $d );
Obviously, modifications to $a, $b, or $c would carry through. Doing
this means that array, hash, and sub junctions make sense and behave
no differently than any other readonly variable.
In fact, this behavior seems mandated given the possibility of tying
variables (or is this a Perl5ism that is being discarded in Perl6?)
Rob
Re: Junctions again (was Re: binding arguments)
On 1/4/06, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Of course, this was introduced for a reason:
>
> sub min($x,$y) {
> $x <= $y ?? $x !! $y
> }
> sub min2($x, $y) {
> if $x <= $y { return $x }
> if $x > $y { return $y }
> }
>
> In the presence of junctions, these two functions are not equivalent.
> In fact, it is possible that both or neither of the conditionals
> succeed in min2(), meaning you could change the order of the if
> statements and it would change the behavior. This is wacky stuff, so
> we said that you have to be aware that you're using a junction for
> "safety".
>
> But now I'm convinced, but I've failed to convince anyone else, that
> the behavior's being wacky doesn't mean that it should be declared,
> but that the behavior is just plain wrong. I figure that if something
> says it's totally ordered (which junctions do simply by being allowed
> arguments to the <= function), both of these functions should always
> be the same. The fact is that junctions are not totally ordered, and
> they shouldn't pretend that they are.
To me, this implies that junctions don't have a complete definition.
Either they're ordered or they're not. Either I can put them in a <=
expression and it makes sense or I can't. If it makes sense, then that
implies that if $x <= $y is true, then $x > $y is false. Otherwise,
the definitions of <= and > have been violated.
And, if I can't put them in a <=, then Perl should complain very
loudly, just as if I put something else that shouldn't be put into <=,
like a Person object. If I call min() or min2() with a Person object
and an array, I should expect loud complaints from the runtime. If a
junction cannot behave itself in a numeric comparison, then similar
complaints should be made.
Rob
Re: Table of Perl 6 "Types"
> I wouldn't see a problem with defining a "Real" role that has a fairly > sparse set of operations. Afterall, a type that does support ++ and -- > (e.g. Int, Num) could easily "does Enumerable" if it wants to declare > that it supports them. What about the scripty-doo side of Perl6? One of the overriding design considerations that Larry put forward at the very beginning was that the "easy things are easy" part of the philosophy would still remain. I want to still be able to do something like perl -pia -e '@F[2]++' somefile.xsv And it just DWIM for numbers like 1.2 ( -> 2.2). If Real is what 1.2 is implicitly coerced into, what do I do now? Remeber a few truisms: * The most common usage of Perl after bad CGIs is systems administration. * The most powerful feature of Perl for sysadmins is the scalar Rob
Re: Table of Perl 6 "Types"
On 1/12/06, Ævar Arnfjörð Bjarmason <[EMAIL PROTECTED]> wrote:
> The "next/prev" semantics are, and should be more general than ±1, I
> just think that ±1 should remain the default for reals & ints.
So, Num (and all types that derive from Num) should have a next of {
@_[0] + 1 } and a prev of { @_[0] - 1 } (boundschecking against the
limits of the type, of course) ... ?
That sounds reasonable and dwimmish to me.
Rob
Re: The old "$x will not stay shared" thing.
On 1/16/06, Larry Wall <[EMAIL PROTECTED]> wrote:
> Yes, at least for any block that really is capturing a closure.
> Perhaps we need to distinguish those from "accidentally" nested
> top-level functions. But undecorated "sub" is more-or-less defined
> to be "our sub" anyway, just as with "package", "module", and "class"
> these days. The only difference is that "our" explicitly introduces
> a lexically scoped alias, while the undecorated form presumably doesn't.
> Though we could break that too, I suppose.
What is the benefit for -not- explicitly introducing a lexically
scoped alias? Is there some performance reason why the undecorated
form wouldn't?
> : * If we insert a call to g() above without calling f() first, should it
> : assume an uninitialized $x, or throw an exception (Pugs currently does
> : the latter)?
>
> An exception is fine, modulo what I said about "accidental" nesting.
> When do you detect the condition? If the inner function can't
> reference $x, does it still fail? On the other hand, we can get into
> "eval" issues where it might or might not reference $x. I'm okay
> with requiring lexical scopes to have some existing relationship
> with dynamic scopes, especially when we know some initialization is
> required.
What other forms would be useful other than "our sub g {...}"? If
they're useful, shouldn't they have keywords?
Rob
Re: Indeterminate forms for the Num type.
On 1/17/06, Audrey Tang <[EMAIL PROTECTED]> wrote: > But putter on #perl6 reports "1" on his amd64. I'd be happy we spec it > has to have to return 1 always for boxed Num types, even though it means > additional cycles for boxed numeric types. Isn't the point of boxing to provide a hardware-independent dependable solution at the cost of additional cycles? Rob
Class methods vs. Instance methods
Today on #perl6, Audrey, Stevan and I were talking about $repr. A
tangent arose where Audrey said that the difference between class
methods and instance methods was simply whether or not the body
contained an attribute access.
Is this true? If it is, then I think it violates polymorphism as
demonstrated by the following:
class Dog {
method tail { "brown and short" }
};
class Chihuahua is Dog {
has $.color;
method tail { $.color _ " and short" }
};
You can say Dog.tail, Dog.new.tail, Chihuahua.new.tail, but not
Chihuahua.tail. That's extremely counter-intuitive.
I think that class methods should be explicitly defined as class
methods and you cannot call a class method upon an instance, just as
you cannot call an instance method upon a class. Plus, this should be
determinable (for the most part) at compile time, which is a bonus,
imho.
Thanks,
Rob
Re: Class methods vs. Instance methods
On 1/18/06, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 18, 2006 at 01:56:53PM -0500, Rob Kinyon wrote:
> : Today on #perl6, Audrey, Stevan and I were talking about $repr. A
> : tangent arose where Audrey said that the difference between class
> : methods and instance methods was simply whether or not the body
> : contained an attribute access.
> :
> : Is this true? If it is, then I think it violates polymorphism as
> : demonstrated by the following:
> :
> : class Dog {
> : method tail { "brown and short" }
> : };
> :
> : class Chihuahua is Dog {
> : has $.color;
> : method tail { $.color _ " and short" }
> : };
> :
> : You can say Dog.tail, Dog.new.tail, Chihuahua.new.tail, but not
> : Chihuahua.tail. That's extremely counter-intuitive.
>
> I don't think it's counterintuitive. You've defined Dog with an
> invariant .tail but not Chihuahua. It's doing exactly what you asked
> for under a prototype view of reality.
Except there are no such things as classes in a prototype view of
reality. Everything is an instance and there are no such things as
class methods. The entire idea that an object (::Dog) can call methods
that are for another object ($fido) is ... well ... it's a little off.
That's like saying any object can call any method from any other
object so long as that method is invariant.
> : I think that class methods should be explicitly defined as class
> : methods and you cannot call a class method upon an instance, just as
> : you cannot call an instance method upon a class. Plus, this should be
> : determinable (for the most part) at compile time, which is a bonus,
> : imho.
>
> I believe this is already determinble at compile time for the most part.
>
> But I have a strong gut-feeling that over the long term it's going to
> be important to be able to view a given object as either a partially
> instantiated class or a partially undefined object, and for that we have
> to break down the false class/instance dichotomy. And to the extent
> that the dichotomy *isn't* false, we're trying to sweep classness into
> the .meta object, which is the *real* class object in Perl 6.
I'm sure you understand the distinction you're making. I know I don't
and I've been trying to follow this discussion for the past year. I'm
may not be the brightest bulb in the chandelier, but I'm no 15W dimmer
switch, either.
Frankly, you should be using people like me, Matt Fowles, and the
other programmers on the list as sounding boards. If we're having
problems understanding the concept, then how are we going to explain
"partially-instantiated classes" on Perlmonks or #perl or clmp? Like
it or not, we're the sergeants in the Perl army. We're the guys
explaining all this stuff to the privates coming up the ranks. It may
be a nice extension to have, but I'm not sure this should be part of
the standard MOP.
Rob
perl6-all@perl.org
On 1/18/06, chromatic <[EMAIL PROTECTED]> wrote:
> On Wednesday 18 January 2006 14:13, Stevan Little wrote:
>
> > Do we really still need to retain the old Perl 5 version of &bless?
> > What purpose does it serve that p6opaque does not do in a better/
> > faster/cleaner way?
>
> Interoperability with Perl 5 code.
Well, for one thing, you can't write OO code in P5. You can write code
that behaves like you're in OO-land and that talks with an OO accent
(so long as you don't look behind the curtain), but it's not OO.
Given that, I'm not sure that conceptual interoperability with P5 code
should be a design goal, particularly in the OO-space. Allowing
methods to be called on references that have been associated with a
given package is an easy addition to the current MOP. Just add
.blessed_into and have a step right before AUTOLOAD (or method_missing
or whatever) to check .blessed_into and try that package, if one is
set.
Also, given that the semantics of a number of items is changing (
"".split(':') anyone?), how closely will P6 really mirror P5 behavior
given identical code?
Rob
perl6-all@perl.org
On 1/18/06, chromatic <[EMAIL PROTECTED]> wrote: > On Wednesday 18 January 2006 17:57, Rob Kinyon wrote: > > > Well, for one thing, you can't write OO code in P5. > > I'll play your semantic game if you play my what-if game. > > I have a fair bit of Perl 5 code. Ponie works. I want to migrate my Perl 5 > code to Perl 6 slowly. Everything new is Perl 6 code. When I have a chance, > I migrate classes and modules from Perl 5 to Perl 6 code. > > I have a handful of Perl 5 classes. One day, I need to subclass one of them. > Per my goal, I do so in Perl 6. Of course, it has to interoperate with the > Perl 5 in the system, per that pesky Liskov rule. If I can specify an > alternate internal representation for the object corresponding to the > appropriate internal representation for the Perl 5 class I'm extending, > great! I think the more relevant question is "How do I subclass a Ruby class in Python and delegate to it from a Perl6 object that's used in a Perl5 module that's implementing the event loop for a Java app?" The answer, of course, is that everything is mediated by Parrot (or whatever VM they all choose to target). Just because one side is Perl6 and the other side is Perl5 doesn't mean that they should have any closer of a relationship than Ruby and Python would. They are separate languages, related only through a common creator, a shared community, and the same VM. Nothing less, nothing more. As for how that will be handled, I would think that it would be as follows: - in Perl6, objects created in another language will be treated as p6opaque (unless some other unbox is a more suitable $repr). - in Perl5, objects created in another language will be treated as inside-out objects. > If not, your programming language sucks and doesn't do what the box leads me > to believe that it should do -- especially if the answer is "Well you > shouldn't want to do that." The box you're talking about is the box with "Parrot" on the cover, not Perl6. And, you most definitely want to be able to do what you're suggesting and it will be possible. You'll just have to give up on the mismeme of &bless, and I think you'll find that oddly freeing. Rob
perl6-all@perl.org
On 1/18/06, chromatic <[EMAIL PROTECTED]> wrote: > On Wednesday 18 January 2006 19:11, Rob Kinyon wrote: > > > As for how that will be handled, I would think that it would be as follows: > > - in Perl6, objects created in another language will be treated as > > p6opaque (unless some other unbox is a more suitable $repr). > > ... and I specify this exactly how? I was intending for that to mean that Parrot might indicate that the representation in Perl6 for a Perl5 object could be p6hash instead of p6opaque, but that might be a little too clever. I was thinking, actually for interoperability with something like C++ where your classes are laid-out-in-memory structs (which is the best reason I've heard for having alternate $repr). There certainly is no good reason within Perl6 itself to muddy up the waters like that. You really want to read http://svn.openfoundry.org/pugs/docs/notes/piln_object_repr_types.pod Rob
perl6-all@perl.org
On 1/18/06, chromatic <[EMAIL PROTECTED]> wrote: > 1) by default, your object is opaque > 2) if you don't want this, you can always use bless() > > For interoperability with Perl 5 classes, I don't want to use an opaque > object. Ergo, I want to use bless() (or something, but does that explain why > I think bless() is important?). No, you want to specify the $repr in CREATE(). But, p6hash will still not be the same as a ref to an HV. Frankly, I think you're better off letting Parrot mediate things the same way it would mediate Ruby and Perl6 or Perl5 and Python. Worrying about it in userland is just going to cause you headaches. Rob
perl6-all@perl.org
On 1/18/06, chromatic <[EMAIL PROTECTED]> wrote: > On Wednesday 18 January 2006 19:39, Rob Kinyon wrote: > > > No, you want to specify the $repr in CREATE(). But, p6hash will still > > not be the same as a ref to an HV. Frankly, I think you're better off > > letting Parrot mediate things the same way it would mediate Ruby and > > Perl6 or Perl5 and Python. Worrying about it in userland is just going > > to cause you headaches. > > Answer me this then -- under your scheme, can I subclass a Perl 5 class with > Perl 6 code, instantiate the subclass, and use that object in Perl 5 code as > if the subclass were Perl 5 code, without rewriting all of my Perl 5 code? You have two cross-language interactions. 1) Subclass a LangX class in LangY 2) Instantiate a LangY class and use that object in LangZ That LangX === LangZ is irrelevant to the discussion. So long as you aren't peeking behind the curtain (method calls only), Parrot should be able to mediate everything. In other words, if your code is good OO code, then you shouldn't have any problems. Rob
perl6-all@perl.org
On 1/18/06, Trey Harris <[EMAIL PROTECTED]> wrote:
> Excuse my ignorance of the finer points, but I thought the reason for
> bless's continued existence was so that the same sort of brilliant OO
> experimentation that Damian and others have done with pure Perl 5 can
> continue to be done in pure Perl 6 without having to hack p6opaque?
That's what the .meta and the MetaObject Protocol is for. Not to
mention that 90% of the hacking done in Class:: and Object:: will
handled by the fact that Perl6 has actual OO syntax. ("Look Ma, no
hands!") You won't need Class::MakeMethods because Perl6 will make
your accessors for you. You won't need Class::Std to protect your
instance data because p6opaque will ... well, it's opaque. :-)
As for the ability to "hook into" the P6 OO system, you'll have
CREATE, BUILD, BUILDALL, true NEXT semantics, and the ability to
completely rewrite the method dispatcher (if you really feel like it).
I think we've gone well beyond &bless.
Rob
perl6-all@perl.org
On 1/19/06, Juerd <[EMAIL PROTECTED]> wrote:
> Rob Kinyon skribis 2006-01-18 20:57 (-0500):
> > Well, for one thing, you can't write OO code in P5.
>
> Nonsense. OO isn't a set of features, and OO isn't syntax.
>
> Granted, syntax can really help to understand OO, and a set of features
> is nice, because it avoids having to re-invent wheels.
>
> But OO is just that: object orientation. It is a way of programming, and
> that can very well be done without any syntax or features for that in
> place.
I've said those very same things on Perlmonks. I stand by them, yet I
still maintain that you cannot write truly OO code in P5.
OOP is all about black-box abstraction. To that end, three items have
been identified as being mostly necessary to achieve that:
1) Polymorphism - aka Liskov substitutability
2) Inheritance - aka specialization
3) Encapsulation
P5 excels at #1, does #2 ok, and fails completely at #3. Now, one can
argue whether the programmer should make the decision as to whether
strong encapsulation is desirable, but the point is that you cannot
create encapsulation in Perl that someone else cannot violate.
Hence, you cannot write OO code in Perl.
> C's filedescriptors are objects/invocants, and so are PHP's MySQL
> resources.
I point you to http://www.perlmonks.org/?node_id=112180 where I say
that Perl's scalars are objects. I have since realized that tilly is
right, particularly after learning a more OO language (which just
happened to be Ruby).
> Perl 5 has syntax for OO, and even a few useful features. Even though
> these are not needed at all to write OO code, it certainly does help
> people to stick to OO design.
>
> And if more features are needed, CPAN has them.
>
> Object orientation is still object orientation if you write it
> differently: "$bar->{foo}->()", if that's how you decide to write a method
> call on $bar, is still OO.
>
> Classes, like OO syntax, are not necessary for OO.
Javascript is a good example of this. Yet, even in JS, you have the
"prototype", which is the "class". Unless you plan on building
everything by hand, you still need a model for the new instance you're
creating. That model is the class. It's not an OO requirement, but an
OO consequence.
> > You can write code that behaves like you're in OO-land and that talks
> > with an OO accent (so long as you don't look behind the curtain), but
> > it's not OO.
>
> Your definition of OO is far too specific for a 2-letter acronym.
OO is a spectrum, not a point. What I was trying to say was that when
comparing the OO you can do in P5 with the OO you will be able to do
in P6, it seems silly (to me) to cripple P6 out of a misguided effort
to maintain backwards compatibility with P5.
Rob
Re: Class methods vs. Instance methods
On 1/18/06, Audrey Tang (autrijus) <[EMAIL PROTECTED]> wrote: > http://cakoose.com/wiki/type_system_terminology#13 "Any practical programming language with structural subtyping will probably let you create and use aliases for type names (so you don't have to write the full form everywhere). However, the underlying type system will only consider the structure of the type when doing its job." What's wrong with Perl doing things that way? duck-typing with names ... sounds like a plan to me ... Rob
Re: Perl 6's &bless is (seriously) broken
To further extend Steve's argument (which I wholeheartedly agree with), I wanted to point out one thing: &bless has nothing to do with OO programming as conceived of in Perl6. It does one thing and only one thing: - tag a reference with a package name. This is used in a few places: - to determine what package the 'meth' function lives in when the syntax $foo->meth( @parms ) is encountered - to determine what ref() should return There are no references in Perl6. In fact, the only think you have in Perl6 is objects, so why do we need to take something that isn't an object (which doesn't exist) and do anything to it, let alone tag it with a package name? Packages don't have anything to do with the class system. If you want to change the behavior of something at runtime, you can do so through .meta, roles, mixins, traits, and the like. &bless was a brilliant idea for Perl5. It's wrong for Perl6. Rob
Re: Perl 6's &bless is (seriously) broken
On 1/19/06, Juerd <[EMAIL PROTECTED]> wrote: > Rob Kinyon skribis 2006-01-19 16:10 (-0500): > > There are no references in Perl6. > I have to admit, though, that I've never seen this statement, or > anything implying it. It's entirely new to me. > > Is your Perl the same as that of other people on this list? :) There are no references in Perl6 in the way Perl5 conceives of references. > Perl still has non-object types. They may represent objects internally, > but they work differently from what we've historically been calling > objects. Especially in assignment, the differences are huge, because an > object is considered a reference, while "real" scalars, arrays and > hashes evaluate to (a list of) their values, or a useful representation > (like the number of elements) when used in non-OO fashion. No. Objects are *NOT* considered references in most languages other than Perl5. Even in C++, the least OO language that could be considered OO, you can have non-reference objects. I'd say "learn Ruby to know what OO is", but I happen to know you already know a nearly-pure OO language - Javascript. Every single 'thing' in JS is an object - you can hang methods off of a string literal or a number. Most objects in JS aren't references. > > &bless was a brilliant idea for Perl5. It's wrong for Perl6. > > I think it's needed to be able to convert Perl 5 code > semi-automatically. > > But you have probably thought about this more than I, so I'll ask you: > what's the alternative? Well, there's two scenarios - you either run your P5 code using Ponie or you attempt to use Larry's "Wondrous Machine of Translation". Me, I choose the former. Now, I don't worry about how objects are mediated between languages - Ponie and Parrot have to do that for me. And, before you start worrying, this is a feature that was planned into Parrot from Day 1. Ruby and Python and Perl6 all have to interoperate, including inheritance from each others' classes. Perl5 <-> Perl6 will be no different. But, if you must use the WMoT, then I suspect the following will happen: 1) The WMoT notices your use of &bless and marks that package as a class and that method as a constructor. 2) It creates a Perl6 class for your use, noting the accesses into the Perl5 reference that you used and calling those attributes. 3) It then creates your BUILD() method, putting all the non-bless components of your new() into it. That's it. No &bless in Perl6 needed. Rob
perl6-all@perl.org
On 1/19/06, chromatic <[EMAIL PROTECTED]> wrote: > On Wednesday 18 January 2006 20:02, Rob Kinyon wrote: > > > On 1/18/06, chromatic <[EMAIL PROTECTED]> wrote: > > > > Answer me this then -- under your scheme, can I subclass a Perl 5 class > > > with Perl 6 code, instantiate the subclass, and use that object in Perl 5 > > > code as if the subclass were Perl 5 code, without rewriting all of my > > > Perl 5 code? > > > > You have two cross-language interactions. > > 1) Subclass a LangX class in LangY > > 2) Instantiate a LangY class and use that object in LangZ > > > That LangX === LangZ is irrelevant to the discussion. > > Unless, of course, if $omeone had promised backwards compatibility with LangZ > 5 from LangY 6. I'm not sure how that promise is broken if Perl 6.0.0 includes Ponie as part of the distribution. > Next question. If Ponie and Perl 6 are both running on Parrot, and if Ponie > has PMCs that represent Perl 5 data containers, such as p5hash, p5array, > p5symbol, and so on, what's the problem with having a Perl 6 object that uses > one of those PMCs as its internal storage? Nothing. Just like it's not a problem if Perl6 uses one of the Ruby-specific PMCs for storage. In fact, the alternate $repr idea is specifically to allow for the use of foreign datatypes as storage. Luke's excellent example is to use a C-struct as your storage. > I realize one of Stevan's objections is "But if you use a Hash, does your > object automatically support the .keys method and .kv and so on?" to which I > reply "No, of course not. That's silly. It just uses the Hash for > *storage*." Storage of what? What are you trying to do that you need to use an object to store your attributes? Why aren't you just using the method -that- object is using? And, for the record, I'm currently working on a proposal to p6l to restrict object representations to unboxed types. So the problem that Stevan is worried about in this objection would become moot. > Is that your objection to bless()? No. My objection to bless() is BUILD() and CREATE(). There's already a mechanism in the P6 OO system for specifying the internal representation of the instance. In fact, if you're crazy enough, you can specify that at runtime. In other words, the functionality of bless() has already been subsumed into the OO system and is called by a few different names. > Or is the question about "Why is there a need for bless() when you can already > pass arguments to CREATE()?" In that case I dunno. Exactly. :-) Rob
Re: Perl 6's &bless is (seriously) broken
On 1/20/06, Juerd <[EMAIL PROTECTED]> wrote: > Note, by the way, that JS has "primitive" strings, and Strings, only the > latter being objects. Fortunately for us, though, a string is > automatically promoted to a String when the string is USED AS an object. In other words, according to userland, everything is an object. > > But, if you must use the WMoT, then I suspect the following will happen: > > 1) The WMoT notices your use of &bless and marks that package as a > > class and that method as a constructor. > > 2) It creates a Perl6 class for your use, noting the accesses into > > the Perl5 reference that you used and calling those attributes. > > 3) It then creates your BUILD() method, putting all the non-bless > > components of your new() into it. > > Doesn't solve the problems as mentioned in this thread, like overlapping > methods. Yeah it does because all $repr's are p6opaque with direct access being converted into attribute access. No method overlap. Rob
perl6-all@perl.org
On 1/19/06, chromatic <[EMAIL PROTECTED]> wrote: > On Thursday 19 January 2006 19:50, Rob Kinyon wrote: > > > Nothing. Just like it's not a problem if Perl6 uses one of the > > Ruby-specific PMCs for storage. In fact, the alternate $repr idea is > > specifically to allow for the use of foreign datatypes as storage. > > Luke's excellent example is to use a C-struct as your storage. > > ... but ... > > > Storage of what? What are you trying to do that you need to use an > > object to store your attributes? Why aren't you just using the method > > -that- object is using? > > I can't reconcile these two paragraphs. The second paragraph was referring solely to where you're dealing with Parrot datatypes only. If you have to go outside of Parrot (to a C lib, for instance), then you do need to know about the storage specifics. > > No. My objection to bless() is BUILD() and CREATE(). There's already a > > mechanism in the P6 OO system for specifying the internal > > representation of the instance. > > This is Perl. The "there should be one obvious way to do it" ship, canoe, > raft, and water wings have sailed, paddled, floated, and inflated. And there is. You can create your own meta-object protocol on top of p6opaque or any other representation you want. This is *Perl6* - you can rewrite the whole damn grammar if you want to. You can use another VM if you want to. (PIL^N runs on Javascript!) I think this entire issue is rising out of the fact that very very few people in this discussion are familiar with the design of the MOP. Stevan and a few others are the primary movers and I'm lucky enough to have been Stevan's sounding board for a few pieces. Once you grok the MOP, it's really hard to imagine wanting to use bless(). It's literally like trying to explain to a BASIC programmer why recursion is good or trying to explain to a C programmer why automatic memory management is handy. The frames of reference are so different that the meaning being trasmitted is not the meaning being received. Rob
perl6-all@perl.org
On 1/20/06, Larry Wall <[EMAIL PROTECTED]> wrote:
[snip really cool blathering]
I don't have much to say on the deeper question, but I have a few
ideas on the P5 -> P6 translation question, especially as it relates
to OO:
1) Don't translate at all. Ponie, delegating to Parrot, is
supposed to handle all of that OO garbage in the same way that Ruby
and Python are going to interact with Perl6. Perl5 and Perl6 are as
similar as Ruby and Python, so you might as well write a translator
between them as one between Perl5 and Perl6.
Pros: Larry doesn't have to do anything more on the WMoT.
Cons: The community, for some reason, really wants this
auto-translator, even though there wasn't one for P4->P5 and P5->P6 is
a greater leap than P4->P5 was.
2) Don't attempt to translate $x->{whatever} (or $x->[2] or
$x->('whatever') ... ) in isolation. If it occurs within a function
defined in a package that has a function that uses bless and it's the
first parameter, it's an attribute access. Otherwise, it's a hash
access.
Pros: It's a nice and easy rule which will work if the programmer
didn't violate encapsulation, only puts methods in classes, and is
generally an all-around nice guy.
Cons: See Pros.
3) Since about half of all classes in P5-land use some module in
Class::* to auto-generate stuff (thus providing a nice place to find
all the attribute names), ask the community to provide a translator
for each of those. Then, use #2 for the others.
Pros: The WMoT can punt in about half the cases.
Cons: The WMoT cannot punt in about half the cases.
Rob
Parrot and PGE will save the day (was Re: "as if" [Was: Selective reuse of storage in &bless.] )
On 1/20/06, Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 20, 2006 at 04:20:54PM -0500, Rob Kinyon wrote:
> > Pros: Larry doesn't have to do anything more on the WMoT.
> > Cons: The community, for some reason, really wants this
> > auto-translator, even though there wasn't one for P4->P5 and P5->P6 is
> > a greater leap than P4->P5 was.
>
> But (as I understood it) the P4->P5 leap was not intended to be so great
> that a translator would be needed. In fact, that confuses cause and effect.
> Because the technology wasn't there to write a translator, it constrained the
> size of the leap. The important part was that for Perl 5 to still be Perl,
> it had to keep running the vast majority of Perl scripts.
>
> In fact, Perl 5 still strives to maintain Perl 1 compatibility (and the
> perl5-porters joke is that even thinking about breaking this is the fastest
> way to summon the thought, er backwards compatibility police with a script
> he's been running unchanged since 1987). Why else can you still:
>
> $ perl -le '$h{1} = "Perl"; print values h'
> Perl
> $ perl -le 'push a, "Perl"; print @a'
> Perl
Now, that's an unadvertised feature! I think I need to revisit some golfs ...
> I believe that the translator is seen as needed (even by @Larry, I think)
> to maintain the same level of continuity in the Perl 5->6 transition as
> Perl 4->5 - your existing monolithic script runs on the newer Perl
> interpreter, and you can edit (within that same file) as and when you need
> to.
>
> Otherwise you're in the situation where you can only inter-operate languages
> the whole file level. Which means that it's the same actions to migrate from
> Perl 5 to (say) Python as from Perl 5 to Perl 6. And somehow I think that
> $Larry has some bias about which language he'd prefer everyone to find it
> easiest to migrate to, even if he's too modest to admit it.
Please don't take offense at this, but I believe you're using 20th
century thinking. The two most important features in Perl6 aren't -in-
Perl6 - they're Parrot and the PGE. Both of them make a translator
unnecessary. More precisely, they make a file-in-P5 to file-in-P6
translator unnecessary because you can have block-level
interoperability.
I'm making a few assumptions here:
1) Since PGE isn't part of Perl6 (because it's written in PIR), it
can be used as the parser/lexer/etc. for any language, not just Perl6.
2) Since PGE can be lexically-scoped, one can change the entire
grammar within a given block, including how variables are referenced,
subroutines are called, etc.
3) Since everything is, at the heart, just a PMC, so long as the
appropriate PIR is emitted, it doesn't matter how the userside code is
written so long as the right parser/lexer/whatever is used to
translate it to PIR.
So, if all three assumptions hold, then your monolithic Perl5 script
can easily inline any Parrot-targeted language you want, simply by
doing the following:
1) Use Ponie.
2) Within a block, import the appropriate PGE module(s) to
redefine the grammar to P6 and do what you need to do.
No translator needed.
Rob
Re: ff and fff [Was: till (the flipflop operator, formerly ..)]
On 1/25/06, Juerd <[EMAIL PROTECTED]> wrote: > Patrick R. Michaud skribis 2006-01-25 13:47 (-0600): > > On Wed, Jan 25, 2006 at 11:37:42AM -0800, Larry Wall wrote: > > > I've changed the flipflop operator/macro to "ff", short for "flipflop". > > > This has several benefits. ... > > ...another of which is that we can use "ff" and "fff" to mean "loud" > > and "really loud" in our perl poetr^H^H^H^H^Hmusic. :-) > > We need pp and ppp for balance. /me wonders who signed up "The Little Einsteins"(tm) for P6l ...
perl6-all@perl.org
On 1/26/06, Stevan Little <[EMAIL PROTECTED]> wrote:
> Actually this might not be a bad approach in this case. Take this for
> instance:
>
> method foo (Foo $self, $key) {
> ((Hash) $self){$key}
> }
>
> The syntax is ugly, but it makes what you are doing more explicit. I
> would also think that in most cases this could be compile time checked
> (if we can check $self's type (Foo), we can make sure Foo does/isa
> Hash).
>
> Here are some other ideas for a typecasting syntax using "as" for the
> keyword (which IIRC is taken for coercion??):
>
> $self as Hash {
> # $self is treated as a Hash inside the block
> $self{$key} = $value;
> }
>
> # it could also return a wrapped
> # $self for use in wider scopes
> my $h = $self as Hash;
> $h{$key} = $value;
Isn't typecasting a DesignSmell? This kind of overloading is, imnsho,
going to cause more coding bugs and is going to be considered a design
flaw in P6.
If there is need to treat something as a Hash, then provide it with a
postcircumfix<{}> and leave it at that. It's highly unlikely that you
will want to add Hash-like behavior to something that already has a
postcircumfix<{}> because it probably has that behavior already.
Rob
perl6-all@perl.org
On 1/26/06, Stevan Little <[EMAIL PROTECTED]> wrote:
> > If there is need to treat something as a Hash, then provide it with a
> > postcircumfix<{}> and leave it at that. It's highly unlikely that you
> > will want to add Hash-like behavior to something that already has a
> > postcircumfix<{}> because it probably has that behavior already.
>
> Well this is in relation to how to deal with an object which is a
> blessed p6hash, in which case you may or may not want to have a
> ^Hash-like interface for it (you might even want to overload the
> ^Hash-like interface too).
[snip]
> Now, in order for C<$self as Hash> to make sense, $self would have to
> be coercable into a Hash in some way. If $self is a blessed p6array
> this might not make that much sense, so we would die because the
> coercion failed. However, if $self is a blessed p6hash, then it would
> make plenty of sense (IMO at least). It would allow us to get at the
> underlying representation without having to sacrifice flexibility in
> the class from which $self came. Basically you could do things like
> this:
>
> class Golum;
>
> method new (Golum $class, Hash %params) {
> $class.bless(%params);
> }
>
> method postcircumfix:<{}> (Golum $self, Any $key, Any $value) {
> die "Nasssty Hobbitses" if $value.does(Hobbit);
> $self as Hash {
> $self{$key} = $value;
> }
> }
How about just inheriting from Hash?
class Gollum extends Hash;
method postcircumfix:<{}> (Golum $self, Any $key, Any $value) {
die "Nasssty Hobbitses" if $value.does(Hobbit);
$self.NEXT.{}( $key, $value );
}
Rob
Re: Instance attributes collision
On 2/14/06, Stevan Little <[EMAIL PROTECTED]> wrote:
> I think that the metaclass (stored in the pseudo-lexical $::CLASS)
> should create a number of anonymous roles on the fly:
>
>role {
> multi method a (::CLASS $self) { ... }
> multi method a (::CLASS $self, Scalar $value) { ... }
>}
>
>role {
> multi method a (::CLASS $self) { ... }
> multi method a (::CLASS $self, Array @value) { ... }
>}
>
> These roles would then be added to the metaclass using the normal
> rules of role composition. (NOTE: I assume that ::CLASS is unbound
> until the role is composed into a class, I think A12 might have stated
> this detail)
>
> Now obviously we have a conflict in our multi-methods. S12 only states
> that multi methods will be compared by their long names (name +
> signature) to resolve ambiguity, it does not state what happens when
> those long names conflict. I propose that they work just as normal
> method conflicts do, which is that both methods are excluded and the
> consuming class is then required to implement that method.
Is it just the first multimethod a(::CLASS $self) from each role being
excluded or are all the multimethod a(...)'s being excluded?
Rob
ACID transactions for in-memory data structures
I've been working on DBM::Deep, a way to have P5's data structures stored on disk instead of RAM. One of the major features I've been adding has been ACID transactions. I'm pretty sure it wouldn't be very feasible to do this natively in P5. But, would it be possible to do it natively in P6? As in, supported within the interpreter vs. through some sort of overloading. Rob
Re: ACID transactions for in-memory data structures
On 5/15/06, Audrey Tang <[EMAIL PROTECTED]> wrote: Rob Kinyon wrote: > I'm pretty sure it wouldn't be very feasible to do this natively in > P5. But, would it be possible to do it natively in P6? As in, > supported within the interpreter vs. through some sort of overloading. Look at "is atomic" in S17draft, and Software Transaction Memory in general? Would there be a way for me to say "Yes, I understand that Perl may not generically understand how to revert this outside resource, such as a database, but I do." and do a catch-type block for the revert? Rob
RE: [PASM] problem opening / reading file
At 02:27 AM 8/13/2002 -0400, Dan Sugalski wrote: >Anyone up to throwing a list of outstanding > problems with the I/O system together? From: Clinton A. Pierce [mailto:[EMAIL PROTECTED]] >I'd volunteer, except that I'm used to grunging > around at the assembler level of I/O (INT 21h!) > or with C's stdio and I don't think that your goal >is either one of these targets. I looked at the io ops a few weeks ago and it looks like only the open and readline are working. The write and read ops are using an incompatable file handle (int instead of FILE). I played around with them a bit and got them working for strings, but didn't go much further than that. If you want, I could take a stab at fixing it, although like Clinton, I'm not sure what the ultimate goal is. I also had a question about the read and write ops for NUM and INT... is it a good idea to be able to read/write in an INT length worth of data when INT size could vary from machine to machine? Or am I missing the reason for those? Thanks. Rob
Re: Pugs on Cygwin
> To make a Cygwin pugs, we would need to use a Cygwin GHC.[1] To the best > of my knowledge, nobody maintains public binaries of that; and there is > also the somewhat scary warning of a binary GHC being "a moving target" > since cygwin1.dll often changes in ABI-breaking ways. In short, a real > Cygwin port of pugs is something of a challenge. It might become easier > if done in cooperation with cygwin.com. This is not going to be me. I don't know Haskell or cygwin1.dll. I have no desire to learn the latter and have the desire but no tuits to learn the former. > Until we find a champion for that cause, I think it would still be useful > to allow pugs to be built, as today, on Windows using Cygwin's gcc and > perl5 (just like Corion makes a native build with -- I think -- cc1.exe > and a homebrew perl5). The path question becomes the same as it is for > any other non-Cygwin tool used in a Cygwin shell; how is it solved there? I think the solution is to provide a Cygwin version of the Directory and IO Haskell modules. I don't know if this is possible in Haskell. I'd prefer to have a PugsDirectory and a PugsIO module and have them be aliases for the standard Directory and IO modules when it's not Cygwin. If it is Cygwin, then wrap every function call with a call to cygpath if the directory or file name begins with '/'. Is this possible? Desirable? Rob
Re: Pugs on Cygwin
I have a "working" pugscc and cannot run the test suite. Should I check in my pugscc changes or post them to the list so that Gaal can run them against a Pugs that has a working test suite? Rob On 5/10/05, Gaal Yahas <[EMAIL PROTECTED]> wrote: > On Tue, May 10, 2005 at 10:00:45AM -0400, Rob Kinyon wrote: > > > Until we find a champion for that cause, I think it would still be useful > > > to allow pugs to be built, as today, on Windows using Cygwin's gcc and > > > perl5 (just like Corion makes a native build with -- I think -- cc1.exe > > > and a homebrew perl5). The path question becomes the same as it is for > > > any other non-Cygwin tool used in a Cygwin shell; how is it solved there? > > > > I think the solution is to provide a Cygwin version of the Directory > > and IO Haskell modules. I don't know if this is possible in Haskell. > > I'd prefer to have a PugsDirectory and a PugsIO module and have them > > be aliases for the standard Directory and IO modules when it's not > > Cygwin. If it is Cygwin, then wrap every function call with a call to > > cygpath if the directory or file name begins with '/'. > > > > Is this possible? Desirable? > > It is possible to put cygpath-like capabilities inside pugs and compile > it in on any win32 build, but it sounds to me like a runtime hit on a > lot of IO, unless someone comes up with the magic to choose which path > mode to work with at pugs start time. > > The alternative is even in Cygwin to put things like C:\ paths in > PERL6LIB and friends. pugscc and the rest of the p5 supporting tools > would need to ignore the fact that they're running under Cygwin and feed > pugs only Windows paths. (BTW, pugscc looks like it can be ported to p6 > already.) > > Let's make a list of things that are broken. For me things mostly work: > the test suit does, if I use the yaml harness (p6); 'make test' and > pugscc do not. Do you know of anything else? > > Are there other issues besides paths? > > -- > Gaal Yahas <[EMAIL PROTECTED]> > http://gaal.livejournal.com/ >
Re: Nested captures
> > But it does raise an important point: the discrepancy between $42 and $/[41] > > *is* a great opportunity for off-by-on errors. Previously, however, @Larry > > have tossed back and forth the possibility of using $0 as the first capture > > variable so that the indices of $/[0], $/[1], $/[2] match up with the > > "names" > > of $0, $1, $2, etc. > > > > I think this error--unintentional, I swear!--argues strongly that internal > > consistency within Perl 6 is more important than historical consistency with > > Perl 5's $1, $2, $3... FWIW, I think that all the /^\$\d+$/ variables should be related to each other, too. Now - here's a question. Can I always address $42 in same way that I could address $2 in P5 at any time? Or, will they only come into scope whenever there was a match higher up? I personally like them only being in scope within the scope of a match, especially under any strictures. Second - is it possible or desirable for @/ to be assignable? I can think of some nice uses for that, primarily in testing ... Rob
Re: single element lists
On 5/11/05, Juerd <[EMAIL PROTECTED]> wrote: > Jonathan Scott Duff skribis 2005-05-11 11:45 (-0500): > > 1. specialise ()[] to parse as (,)[] > > 2. scalars are singleton lists, so ()[] naturally > > 3. make (1)[0] die horribly. > > #2 implies that (1)[0][0][0][0] == 1 > > #1 means that (1)[0] == 1 and (1)[0][0] is an error > > #1 also means that ($aref)[0] is $aref, rather than $aref[0]. > > I pick #2, also because I think being able to pass scalars where arrays > are expected simplifies other parts of the language as well. #2 is also more intuitive and comfortable. () in P5 constructs a list, which is why (split ' ', $foo)[0] works so nicely.
Re: Numification of captured match
On 5/12/05, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> On Thu, May 12, 2005 at 02:55:36PM -0500, Patrick R. Michaud wrote:
> > On Fri, May 13, 2005 at 03:23:20AM +0800, Autrijus Tang wrote:
> > > Is it really intended that we get into habit of writing this?
> > >
> > > if 'localhost:80' ~~ /^(.+)\:(\d+)$/ {
> > > my $socket = connect(~$0, +$1);
> > > }
> > >
> > > It looks... weird. :)
> >
> > And it would have to be
> >
> > if 'localhost:80' ~~ /^(.+)\:(\d+)$/ {
> > my $socket = connect(~$0, ~$1);
> > }
> >
> > because +$1 still evaluates to 1.
>
> That's some subtle evil.
>
> > My suggestion is that a match object in numeric context is the
> > same as evaluating its string value in a numeric context.
>
> While I agree that this would be the right behavior it still feels
> special-casey, hackish and wrong.
>
> If, as an optimization, you could tell PGE that you didn't need Match
> objects and only cared about the string results of your captures, that
> might be better. For instance,
>
> if 'localhost:80' ~~ m:s/^(.+)\:(\d+)$/ {
> my $socket = connect($0, $1);
> }
> :s for :string (assuming that hasn't already been taken)
What about the fact that anything matching (\d+) is going to be an Int
and anything matching (.+) is going to be a String, and so forth.
There is sufficient information in the regex for P6 to know that $0
should smart-convert into a String and $1 should smart-convert into a
Int. Can't we just do that?
Rob
Re: Plethora of operators
On 5/14/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Sat, May 14, 2005 at 01:36:22PM -0500, Rod Adams wrote:
> : Larry Wall wrote:
> :
> : >On Sat, May 14, 2005 at 12:51:32PM -0500, Rod Adams wrote:
> : >
> : >: Unless, of course, there is some subtle difference between a 3-d hash
> : >: and a hash of hashes of hashes that invalidates this.
> : >
> : >No difference, I hope. The multidimensional notation is meant
> : >to extend to HoH and AoA transparently (as well as HoA and AoH).
> : >Since a variable's dimensionality is always declared (and a container
> : >object's dimensionality generated at "new" time), we shouldn't have
> : >to worry about whether to add dimensions or autovivify a reference.
> : >Either there's storage already allocated, or we autovivify.
> : >
> : >
> : Hmm. So if I say:
> :
> :@a = [ { a => 1, b => 2}, { a => 3, b => 4 } ];
> :
> : Can I then say:
> :
> :$x = @a[1;'b'];
> :
> : And get $x = 4?
>
> Probably not, but @a{1;'b'} might. I think what we've said before is
> that .[] allows the optmimizer to assume numeric subscripting only,
> while .{} is the more general form.
So, does this mean that I can do something like:
@a = [ 1 .. 4 ];
$x = @a{2};
and have $x == 3? If so, is there any reason (other than clarity) to
use the @a[] notation? The @ already indicates you have an array vs.
the % which indicates hash. Is there a reason to have the subscripting
notation also be different?
I understand why it was different in P5, given that you needed to
differentiate $x->[2] and $x->{2} and allow the reader to know whether
$x was an arrayref or hashref. But, that need is gone from P6. (Isn't
it?)
Rob
Re: ^method ?
On 5/14/05, Rod Adams <[EMAIL PROTECTED]> wrote:
> Jonathan Worthington wrote:
>
> > "Brent 'Dax' Royal-Gordon" <[EMAIL PROTECTED]> wrote:
> >
> >> Like the decision about which side of the road cars should drive on,
> >> it really doesn't matter *which* choice is taken, as long as
> >> *something* is decided.
> >
> > The only thing is, there already is a decided way to do it so far as I
> > can see...
>
> I think the thing most people see wrong with $?SELF is that it's a
> huffman level of 6, all shifted (on std US keyboards, at least). It's a
> 7 when you add the dot. I'm not sure if it deserves a huffman level of 1
> (a la ^), but I would think 2 or 3 is merited. While I agree almost
> entirely with Damian's post, I have to say that these days it's
> annoyingly common for projects to force a OO paradigm. In the OO code I
> write, there tend to be a handful of "heavy" methods, which tend not to
> call other methods, and a heaping handful of "light" 1-5 line wrapper
> methods which coordinate the calling of the heavy methods. (The heavy
> methods tend to be "private" and the workhorses, the light methods
> provide the public interface). I'm certain that others structure their
> code differently.
>
> That said, what I believe I've heard as the major hold up all the
> shortened versions is that there is no general consensus on what it
> should be. So I propose a list of the options, and have people sound off
> as being Favorable/Neutral/Unfavorable on each, to get a feel for where
> people on this list actually stand on the issue.
>
> Here's the list as I've heard them:
>
> $?SELF, and nothing else by default.
>
> $_ bound to $?SELF at start of method.
>
> o.
>
> O.
>
> this.
>
> self.
>
> me.
>
> ^
>
> ->
>
> _
>
> ° (an idea I just had. would likely need a 7-bit option as well)
>
> ..
What's wrong with just defaulting to $self? That's standard P5 OO,
expected everywhere, and you can rename it if you want in the method
definition (which is a nice place). None of this package-global "use
self ^;" stuff that's both magic-at-a-distance and lexically scoped.
("no self ^;" anyone?)
You can't huffman-code everything to 0 everywhere. $self is 5
characters, well-known, very similar to other languages (like JS,
Java, and C++) and only one of the characters is shifted.
Rob
Re: ^method ?
On 5/15/05, Juerd <[EMAIL PROTECTED]> wrote:
> Autrijus Tang skribis 2005-05-15 19:28 (+0800):
> > On Sun, May 15, 2005 at 01:19:53PM +0200, Juerd wrote:
> > > Or was your choice of words poor, and did you not mean to discuss the
> > > dot's *default*, but instead a standard way to write the current
> > > invocant?
> > I think what Rob suggested is that:
> > method ($foo)
> > means
> > method ($self: $foo)
>
> Then I hereby apologise to Rob for my own poor choice of words.
>
> I don't like the idea of having a normal identifier ever used by
> default, except $_, which is already aliased to the invocant.
Autrijus is much more eloquent that (apparently) I can ever hope to
be. Thank you.
If I understand correctly, we're discussing what should happen if you
do something like .method($foo) within another method and if there
should be shorthand way of writing whatever it is.
Right now, P6 has $?SELF and I'm saying that instead of using $?SELF,
we should use $self wherever $?SELF would be used. $_ is still the
topic and would be the default invocant if you have .method($foo).
What I'm saying is that you can have
method ( Int foo ) {
$self.otherMethod( foo );
}
and it will DWIM. Just like Java, C++, and Javascript. (Yes, I'm using
JS as part of my argument.)
If you have
method ( Int foo ) {
.otherMethod( foo );
}
That would be
method ( Int foo ) {
$_.otherMethod( foo );
}
Just like expected.
Rob
Re: ./method
On 5/15/05, Juerd <[EMAIL PROTECTED]> wrote: > Brad Bowman skribis 2005-05-16 9:56 (+1000): > > Would it conflict with range + pattern? Or has that changed anyway? > > No, "./" and "../" are prefix only, so they cannot clash with an infix > operator like "..". How would print "Foo" while $self../method; parse? What does the parser do when it sees "../"? I know what it will do when it sees that ../method terminates the condition. But, will it backtrack? Rob
Re: Quick question: '1.28' * '2.56'
> Maybe s/Num/NumLike/ or something? Anyway, that's how I think of it > at least: not that a Str is converted into a Num, but rather that > certain Strs are Nums. If that's the case, then if I change a variable that isa Str (that isa Num), does it change what it inherits from? Rob
Re: reduce metaoperator on an empty list
On 5/18/05, Stuart Cook <[EMAIL PROTECTED]> wrote: > To summarise what I think everyone is saying, []-reducing an empty > list yields either: > > 1) undef (which may or may not contain an exception), or > 2) some unit/identity value that is a trait of the operator, > > depending on whether or not people think (2) is actually a good idea. I would think that the Principle of Least Surprise points to (1), given that the standard explanation of the [EMAIL PROTECTED] is eval join( '+', @x ) ... Rob
Re: Perl development server
> If you want access, please let me know. I will send you a temporary > password by e-mail, that I expect you to change the first time you get > the chance. I'd like one. > The box won't have an SVN mirror unless someone puts it there. There > won't be a smoke test unless someone writes the script. It's a community > machine, and users are expected to fill in the details. Maybe we should divvy these tasks out. It wouldn't do that have two people smoke-testing on the exact same machine or to have two SVN mirrors ... > Also, this new machine needs a hostname. Please help me think of a cute > name! I prefer a short hostname with less than 9 letters. dev.pugscode.org seems indicated ... Rob
Re: Perl development server
On 5/23/05, Juerd <[EMAIL PROTECTED]> wrote: > Rob Kinyon skribis 2005-05-23 11:22 (-0400): > > I'd like one. > > Sure - just think of a nice catchy username! :) robkinyon please - it's catchy enough. > > Maybe we should divvy these tasks out. It wouldn't do that have two > > people smoke-testing on the exact same machine or to have two SVN > > mirrors ... > > Good idea, will you take the task of managing these decisions? Unfortunately, I have no tuits, otherwise I would love to. Porting PREFIX from EU::MM to M::B is going to take all of my available time, assuming I have any after the baby's born. Rob
Re: (OT) Re: Perl development server
On 5/24/05, Michele Dondi <[EMAIL PROTECTED]> wrote: > On Tue, 24 May 2005, Herbert Snorrason wrote: > > > Icelandic: laukur (Incidentally, none of you will ever guess how to > > correctly pronounce that.) > > Incidentally, would 'laukurdottir' be a proper Icelandic offence? :-) "daughter of an onion" ?? I can't be translating that right ... Rob
Reductions, junctions, hashslices, and cribbage scoring
(This post references the discussion at http://www.perlmonks.org/?node_id=458728, particularly dragonchild's response at the bottom.) For those who don't know, cribbage is a game where each player has access to 4 cards, plus a community card. Various card combinations score points. The one in question is when cards add up to 15. If you have a group of cards that add up to 15, you receive 2 points. This is for every group, so if you have a ten and 2 fives, you get 4 points. Two tens and two fives is 8 points. Face cards are worth 10 and aces are 1, for these purposes. I proposed the following: # Fifteens $score += 2 * all( 15 == [EMAIL PROTECTED] any( 0 .. 4 ) } ); * Is this syntax legal? * Does it do what I want it to do? * Is there another way? Thanks, Rob
Re: (1,(2,3),4)[2]
> Is giving "=" a higher precedence than "," still considered A Good Thing? > > I'm not familiar with the reasoning behind the current situation, but > I'm struggling to come up with any good reasons for keeping it. > > Consider the alternative: > > my $a, $b = 1, 2; # $b should contain 2, not 1 I read this as (my $a), ($b=1), 2; The comma separates clauses in English (and other languages). Why should it not be so in Perl? If you need parens, then use them. I believe it was Larry who said "When in doubt, parenthesize. At the very least, people can bounce on them with % in vi."
Re: Reductions, junctions, hashslices, and cribbage scoring
> Assuming you write the subset coroutine above, how about
>
> $score +=
> ( subsets(0..4) ==> map { 2 * (15 == [+] @[EMAIL PROTECTED]) } ==> [+] )
Working on it last night and this morning, I ended up with the
following, very similar rewrite.
sub gen_idx_powerset (Int $size is copy) returns Array {
my @c = ([]);
for 0 .. $size-1 -> $i {
push @c, (map { [EMAIL PROTECTED], $i] }, @c);
}
return @c;
}
# Fifteens
$score += 2 * grep {
15 == [+]( @[EMAIL PROTECTED]>>. )
}, gen_idx_powerset( [EMAIL PROTECTED] );
(Also available at http://www.perlmonks.org/?node_id=460666)
(I had an error in my original posting. @hand is an AoH. My original
should have hypered to . like my second one does.)
Question: Is it possible using hypers and the like to replace the
gen_idx_powerset() sub with an inline expression? I'm not worried
about maintainability - I wanna see what the new ops can do!
Thanks,
Rob
$*OS and OS::* mixins
I was thinking on the drive home how to write some of the File::Spec functions in P6. I realized that it would be really neat if $*OS did one of a bunch of mixins (maybe OS::unix, OS::win32, OS::vms, etc). That way, you could multimethod the various functions, using junctions and Any to provide a default. Rob
Unicode Operators cheatsheet, please!
I would love to see a document (one per editor) that describes the Unicode characters in use and how to make them. The Set implementation in Pugs uses (at last count) 20 different Unicode characters as operators. While I'm sure these documents exist on the web somewhere, since P6 is the first time most of us will be using these operators, it'd be nice if P6 provided a nice cheatsheet for them. Thanks, Rob
Syntax of "use"/"require"
(This thread is referencing http://www.perlmonks.org/?node_id=461105) I'd like to start writing the Module::Build/ExtUtils::MakeMaker for Pugs. One of the first things that was mentioned was that the syntax for use needs to support specifying the exact version or range of versions you want to have. There has also been mention of the fact that module installation needs to tag the author, as well as other features. Would someone please mind listing all the functionality desired for module installation as seen from "use"? Thanks, Rob
Re: Syntax of "use"/"require"
On 5/28/05, Rob Kinyon <[EMAIL PROTECTED]> wrote: > (This thread is referencing http://www.perlmonks.org/?node_id=461105) > > I'd like to start writing the Module::Build/ExtUtils::MakeMaker for > Pugs. One of the first things that was mentioned was that the syntax > for use needs to support specifying the exact version or range of > versions you want to have. There has also been mention of the fact > that module installation needs to tag the author, as well as other > features. > > Would someone please mind listing all the functionality desired for > module installation as seen from "use"? Note: I've read S11. I was asking more for the backstory. 1) Does this mean that there can be two different Dog-1.2.1, one by cpan:JRANDOM and another by cpan:KRANDOM? 2) Is @INC still searched in order, providing the first one that matches the full specification? Some related questions: 1) Is it possible for "use" to expose the functionality it uses to find the right module to other modules? For example, the module installer I want to write would have to have that logic and I'd rather not duplicate it. 2) That functionality I referred to - theorbtwo on Perlmonks asked for the ability to provide mixins that would direct how some of the functionality worked. Would this be possible? 3) The P6 version of XS - will it be handled at the VM level or the Perl level? I'm assuming the VM level, which then leads to: 4) "use" and non-Perl code - One of the touted things about using Parrot is that a P6 program will be able to access code in any language that targets Parrot. How on earth will that work? 5) Mixed-language distributions - how should a P6 distro builder handle that? How should a P6 distro installer handle that? How should C6PAN handle that? 6) Is there a useful distinction to be made between modules/classes and distributions? I think there is when discussing uninstalling. I install Dog and it provides Dog::Retriever. If I uninstall Dog, it should also uninstall Dog::Retriever. 7) This leads to the thought that a distribution should have a name separate from any of the components within it. I expect that, like URI or Template Toolkit, there will be a component in the distribution that has the same name as the distro, but that will be custom and not law. Sorry for the self-reply, but I realized I hadn't provided enough information. Thanks, Rob
Re: date and time formatting
On 5/31/05, Nathan Gray <[EMAIL PROTECTED]> wrote: > As I am interested in human-readable dates and times, and having found > no conclusive discussion on time formatting, I make my recommendation > for a syntax (to start discussion, and allow for date formatting to be > implemented in pugs): What's wrong with porting DateTime? Rob
Re: date and time formatting
> > What's wrong with porting DateTime? > > It's back to the old question of "what's in core?" Are dates and > times something that are used in such a large proportion of programs > that they deserve to be shipped in the basic grammar? Or perhaps in > the basic set of packages? > > Perl 5 has an entire swath of modules designed to manipulate dates > and times; this suggests that they are (A) commonly used and (B) > something that people feel very strongly about the semantics of. Which still begs the question - why not port DateTime to P6? Why can't installing a module provide new keywords? Rob
Re: date and time formatting
> - I didn't say we shouldn't port DateTime. My point was simply that, > based on the amount of date-related code on CPAN, this is an issue > that many people care about quite a bit. We would probably be well > served to consider it carefully and decide on what semantics we > really want. Maybe DateTime is exactly what everyone wants and all > we need to do is port it. On the other hand, there is something to > be said for Nathan's approach; isn't it worth discussing? What I'm trying to get at isn't that DateTime's API should be preserved. I'm saying that the concept of DateTime should be ported. Core or not core - it doesn't matter. When use'd (or installed), it should override now() (and anyone else we can think of) to return an object that DWIMs, plus provides the interface you've outlined below. > Perhaps something like the typed operations that were discussed > recently: > > my ($launch_date = now() + 6 weeks) but time(9am); > say "We will launch on a $lauch_date.day_of_week, at > $launch_date.time_of_day."; > say "This gives us " . $launch_date but hours . " hours, > including weekends and evenings."; Sure. $launch_date is of type DateTime. It will numify to the seconds-since-the-epoch, stringify to some date string, and provide all the neat-o-keen methods you want it to have. Frankly, I think we're in violent agreement here. I don't think this is something that needs to be built into the language. This is something that should be strongly-recommended for downloading. Kinda like you always expect DBI to be around when you go to a new major client, but it's not core. Well, I always expect DBI to be around ... :-) Rob
Re: Unicode Operators cheatsheet, please!
xOn 5/31/05, Sam Vilain <[EMAIL PROTECTED]> wrote: > Rob Kinyon wrote: > > I would love to see a document (one per editor) that describes the > > Unicode characters in use and how to make them. The Set implementation > > in Pugs uses (at last count) 20 different Unicode characters as > > operators. > > I have updated the unicode quickref, and started a Perlmonks discussion node > for this to be explored - see http://www.perlmonks.org/index.pl?node_id=462246 As I replied on Perlmonks, it would be more helpful if the Compose keys were listed and not just the ASCII versions. Plus, a quick primer on how to enable Unicode in your favorite editor. I don't know about Emacs, but the Vim documentation on multibyte is difficult to work with, at best. Thanks, Rob
Re: reduce metaoperator on an empty list
> > $ordered = [<] @array; This is asking "Is @array ordered?" In the case of a 0-element or 1-element array, the answer is "It is not disordered", which means $ordered is true. $ordered = ! [!<] @array; Rob
Re: date and time formatting
> localtime() and gmtime() seem fairly core to me. The array contexts are > simple, and the scalar context is an RFC valid string. Nothing too heavy > there. The time() function is "typically" only moderately useful without > localtime(). This is true if the time() function returns a simple scalar containing seconds since the Unix epoch. If, however, it returned a DateTime object that numified to said value, but provided both localtime() and gmtime() methods (and a whole lot more) ... wouldn't that be better? Rob
Re: reduce metaoperator on an empty list
On 6/6/05, Sam Vilain <[EMAIL PROTECTED]> wrote: > Roger Hale wrote: > > This is why I would rather the o -> [o] circumfixion left [o] an infix, > > not prefix operator. I would rather be explicit about my identity: > > $product = 1 [*] @array; > > Hmm. Not all operators *have* an identity. So, what's wrong with not providing an identity? It's not like we cannot have a module that says "[*] will be its own operator that defaults to 1, [+] will default to 0", and so forth. In fact, I can easily see a module like that being very useful. Remember - the language DOES NOT have to provide the sinecure for all situations. Discussions like this only emphasize that fact. Give it a module and let it go. In fact, if there's two different and competing implementations for the reduce meta-operator, then maybe it's better to provide a reduce-noident and reduce-ident and let people consciously choose which one they want to use ... Rob
Re: How much do we close over?
> Piers Cawley said: > in other words, some way of declaring that a subroutine wants to hang onto > every lexical it can see in its lexical stack, not matter what static analysis > may say. I'm not arguing with the idea, in general. I just want to point out that this implies that you're going to hold onto every single file-scoped lexical, leading to quite a bit of action-at-a-distance. Maybe, instead, you should say "sub is lexical_stack(N)" where N is the number of scoping levels it will hold onto in addition to any lexical it actually refers to. I would have 0 be the innermost scope, 1 be the enclosing scope, etc. Rob
Parrot and features (was Re: [RELEASE] Pugs 6.2.7 is released!)
> That statement talks about Parrot. As soon as Pugs targets Parrot -- > which is what I'm working on right now -- you can run cross-compiled > Perl 6 program s on PocketPC. Question: Given that Parrot isn't complete, will there be a time where certain Pugs features are available when targeting GHC, but not when targeting Parrot? Rob
Re: Closed Classes Polemic (was Re: What the heck is a submethod (good for))
On 10/12/05, chromatic <[EMAIL PROTECTED]> wrote: > On Wed, 2005-10-12 at 21:50 +0200, Yuval Kogman wrote: > > > This has even more implications with closed classes to which you > > don't have source level access, and if this can happen it will > > happen - i'm pretty sure that some commercial database vendors would > > release closed source DBDs, for example. > > Closed classes should not exist. > > At least, they should only exist if the person *running* Perl 6 wants > them to exist -- never if merely the class writer wants to close them. I'm not sure y'all are talking apples and apples. Yuval is talking about lack of source-level access and the class being closed. I'm not quite sure how we end up with a lack of source-level access, particularly as that locks me, the user of your module, into one specific P6 interpreter (presumably Parrot). Given the work that Autrijus and company have been doing with PIL and Pugs in general, closing the source (presumably by releasing Parrot bytecode) isn't going to really work. (Plus, I can't imagine that a reverser for Parrot code is going to be that hard to write.) Furthermore, is releasing just the Parrot bytecode going to work in multi-lingual apps? Aren't there optimizations that may not be appropriate before all the languages are known? (I'm completely out on a limb, here.) That said, I agree with chromatic closing (or finalizing) a class should be the action of the consumer, not the producer. Maybe the producer could signal his/her desire to close the class when some phase is finished. That would mean the consumer could either modify the class before that phase is finished and/or the consumer could intercept the request for finalization. Alternately, maybe you have a pragma that says "Finalize all classes unless I specify that it should remain open." Maybe, we need a negation for close? keep_open? Rob
Re: Proposal to make class method non-inheritable
All - I'm partly to blame for this thread because I put the idea into Steve's head that class methods being inheritable may be dogma and not a useful thing. Mea culpa. That said, I want to put forward a possible reason why you would want class methods to be inheritable - to provide pure functions. If we go back to every function/method/subroutine being behavior, it's pretty evident that you need some state for that behavior to operate upon. In a procedural function, the state is provided. In an object, that state is both provided and inherent in the instance the method is operating upon. In functional languages, functions maintain their own state through closures, continuations, and the like. I might want to provide in a base class a set of useful sorting routines or other such items. These would be true procedural functions and there would be a warning thrown if it accessed class state. Rob
Re: Closed Classes Polemic (was Re: What the heck is a submethod (good for))
> I think this is an opportune time for me to express that I think the > ability to close-source a module is important. I love open source, > and I couldn't imagine writing anything by myself that I wouldn't > share. But in order for Perl to be taken seriously as a commercial > client-side language, it must be possible to close the source. I > started writing a game with a few friends last year, and as we were > picking our implementation strategy, using Perl as the primary > "sequencing engine" for non-time-critical tasks was immediately > discounted when I commented that anybody can look at your perl source > if they want to. I'd be interested in finding out how this is reasonably feasible for, given that you just said a disassembler for Parrot is going to be relatively simple due to the level of introspection Perl is going to require. Of course, given that Parrot is the ultimate interoperability swiss army knife, one could envision a language without the introspection Perl requires (such as C) that would target Parrot quite nicely. (Isn't Carrot the name for this push? I haven't kept up with the Parrot list.) Then, disassembling that bytecode back to its original form becomes much less desirable. > Of course, there is no argument there for allowing closed-source > *modules*, just complete applications. But I'm sure you could fish > one out involving dynamic loading, or modding, or whatever you want to > call it. The argument that was made was for closing modules, not applications. Specifically, a DB vendor might be more comfortable providing a DBD for their product(s) if they could close the source.
Re: Closed Classes Polemic (was Re: What the heck is a submethod (good for))
On 10/13/05, John Macdonald <[EMAIL PROTECTED]> wrote: > Just because you can't make locking perfect does not mean it > has no value. Acme::Bleach it is!
Re: Custom Metaclass and Inheritance of Class Methods
> == CONCLUSION / WRAP-UP > > So, now that I have sufficiently bored you all to tears, I will do a > quick re-cap of the main question, and the possible solutions. > > Should metaclasses be "inherited" along normal class lines? > > Meaning that if Foo uses a custom metaclass, and Bar isa Foo, then > Bar also uses that metaclass. > > If we say yes, then I think it is clear that in order to get a sane > method and predictable resolution order the custom metaclass would > always need to precede the inherited eigenclass in the superclass > list. (see the last example above). > > If we say no, then we need to introduce another anyonomous class into > our mix, which we call an 'x' class. The 'x' class would need to use > a breath-first dispatch order in order to produce a sane and > predictable method resolution order. I would like to expand on my position in the discussion Steve and I had, which is the "no" position. The crux of my view is that Foo is an instance of some custom metaclass. Bar is an instance of Class (for the sake of argument). Foo and Bar are unrelated, save for the fact that instances created by Bar's new() function will have access to all the behaviors and state that instances created by Foo's new() function will have. This is why I also feel that class methods shouldn't have the same MRO as instance methods, but that's a moot discussion. Rob
Should roles and classes be merged?
In the discussions I've had with Steve, one thing that always nagged me - what's the difference between a "class" and a "role"? I couldn't fix it in my head why there were two separate concepts. Steve, yesterday, mentioned to me that in the metamodel that he's got so far, Class does Role. This means that you can have Class A does Class B, and it will DWIM. Additionally, Larry has said that he wants to be able to instantiate a role. This makes gut-sense to me. A role is really just a "class snippet", complete or not. You can compose these snippets together to make a larger class. Or, in many cases, you can just instantiate the "snippet" and have a viable instance. You can also have an incomplete snippet, just as you can have an incomplete class. This could be useful for things like interfaces. Now, you can have your class inherit from another class, compose itself from other classes, or both! It's completely up to you. You can have your roles in an inheritance hierarchy, and it will all just DWIM. What this means is that classes and roles both quack, swim, and lay eggs. They're both just ducks. Given that, there's no need for two separate concepts in the implementation. It just makes for a more complex implementation. I need to stress that I'm not suggesting that the keyword "role" be removed. It won't be the first time we have keywords that mean the same thing, just with a little sugar added. It definitely improves maintainability to have separate keywords for separate ideas, even if they're implemented identically. Thanks, Rob
Re: Should roles and classes be merged?
On 10/14/05, Larry Wall <[EMAIL PROTECTED]> wrote: > : I need to stress that I'm not suggesting that the keyword "role" > : be removed. It won't be the first time we have keywords that mean the > : same thing, just with a little sugar added. It definitely improves > : maintainability to have separate keywords for separate ideas, even if > : they're implemented identically. > > Certainly a different keyword can be used to convey a different intent. > And because there's a different intent, we can have different defaults > for them, at minimum. > > But I think it goes a little deeper than that. Not to put too fine > a point on it, classes want to be open, and roles want to be closed. > Let's not forget that the main point of roles is to commit to units > of behavior that can be composed into classes (and other roles) > at compile time. It's your basic mutable/immutable distinction. > The compiler can rely on immutable values not changing. Ok. So, in essence, a role is a class that defaults to being closed and a class is a role that defaults to being open. Am I rephrasing you correctly? If so, then they're really the same beast under the hood, just with different default behaviors. > Going the other direction, you could also use a class as if it > were a role, but only by taking a snapshot of its current value. > If you're planning to modify your base class after that, you'd > better be using inheritance rather than composition, or the derived > class won't see the change to the base class, and that would be > unfortunate. As you said in the recent class methods thread, it won't be the first time the programmer would be surprised that the computer did exactly what it was told to do. If you choose to compose, you're fixing the behaviors/state at the time of composition, regardless of what happens after composition. If you choose to inherit, you're not fixing anything (save when you choose to close). > It's bad enough that you might have to notify all > the existing objects that one of its base classes has been modified. > Doing that notification to objects of classes that have composed roles > with compile-time assumptions would be a nightmare of pessimization. > The first implementation of Perl 6 might not make use of optimizations > based on compile-time composition, but we need to leave that door open. Why would that notification need to be done? I, the programmer, chose to compose class A into class B. If I then change class A, I do -not- want class B to see those changes. Granted, it's an unmaintainable pile of dreck, but it's MY unmaintainable pile of dreck. And, Perl shouldn't get in the way of my ability to create piles of dreck. I think inheritable class methods are horrid, but I do agree that Perl should give you as much rope as you want. Rob
Re: top 5 list needed
Some other features:
1) You can write your program in any combination of programming styles
and languages, as you see fit. Thus, you can use your OO library
written in Ruby, that really fast C routine, and your Perl code, all
in one place.
2) There are a large number of operators that support list
manipulation, such as the zipper, the ==> and <== operators, reduce,
and others I can't remember in addition to P5's map, grep, and sort.
3) Macros. Nuff said.
4) More declarative syntax. This is more of a handwavy, but the syntax
feels (to me) as if it's more declarative than before. For example,
for @x -> $x { ... }
for @x -> $x, $y { ... }
That reads like a math proof. "For all X, do such-and-such".
Rob
Re: Making Wrong Code Type Wrong
[snip] Let me rephrase to see if I understand you - you like the fact that boxed types + roles applied to those types + compile-time type checking/inference allows you to tag a piece of information (int, char, string, obj, whatever) with arbitrary metadata. Add that to the fact that you can lexically mark certain function signatures as checking against said arbitary metadata and you can provide taint-checking to an arbitrary complexity. Yeah, that's cool. :-) Rob
Re: syntax for accessing multiple versions of a module
On 10/18/05, Juerd <[EMAIL PROTECTED]> wrote: > Nicholas Clark skribis 2005-10-18 22:41 (+0100): > > my $foo = DBI(1.38)->new(); > > my $bar = DBI(1.40)->new(); > > I like this syntax, and have a somewhat relevant question: can a module > be aliased entirely, including all its subclasses/-roles/-.*? > > Something like > > use DBI as RealDBI; > use MyDBI as DBI; Since a Package or a Module can be a scalar, there shouldn't be a reason why this isn't possible. Rob
Re: top 5 list needed
On 10/18/05, Uri Guttman <[EMAIL PROTECTED]> wrote: > >>>>> "SL" == Stevan Little <[EMAIL PROTECTED]> writes: > > SL> On Oct 18, 2005, at 1:45 PM, Luke Palmer wrote: > > >> On 10/18/05, Rob Kinyon <[EMAIL PROTECTED]> wrote: > >> > >>> 3) Macros. Nuff said. > >>> > >> > >> Not quite. Lispish macros, that is, macros that let you look at what > >> you're expanding. > > SL> To further expand on this, they will be AST-manipulating macros (LISP > SL> style) rather than text-replacing macros (C style). > > my impression is that both styles are supported as you can return either > text or an AST (compiled code) from a macro. That sounds really ... inefficient. For that to work, you'd have to have seen the macro definition earlier in the parse cycle, then encounter the call to the macro (thus consuming the token), unshift the tokens of the macro into the parse queue (thus necessitating a parse queue), then reparse the whole block because of potential bracing issues. Text-substitution macros would have to be handled in an earlier pass, but the macro might be referencing items from BEGIN blocks already seen ... It's called a preprocessor in C for a reason. Rob
Re: syntax for accessing multiple versions of a module
> Another school of thought would be that "Dog" alone would be > considered ambiguious and so we would just alias far enough to be > clear, like this: > >Dog => Ambiguity Error! >Dog-1.2.1 => Dog-1.2.1-cpan:JRANDOM >Dog-0.0.2 => Dog-0.0.2-cpan:LWALL > > Of course, this means that if I also load "Dog-1.2.1-cpan:LWALL" that > the table looks like this: > >Dog => Ambiguity Error! >Dog-1.2.1 => Ambiguity Error! >Dog-0.0.2 => Dog-0.0.2-cpan:LWALL > > And the user is now forced to add the cpan id to get Dog-1.2.1. I am > not sure how strict @Larry wants this to be. NB: Dog-*-cpan:LWALL and Dog-*-cpan:JRANDOM, as well as *-*-cpan:LWALL are also needed for entry into the mix because if there's only one module loaded that is signed by cpan:LWALL, that should be sufficient disambiguation for the parser. (How maintainable that is, I'll leave as an exercise for the reader.) Rob
