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
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: 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
perl6-language@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
perl6-language@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
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 ...
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
perl6-language@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
perl6-language@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
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-language@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/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
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: 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
perl6-language@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
perl6-language@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-language@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-language@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-language@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-language@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-language@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
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
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: 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
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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
[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: 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: 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
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: 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.
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: 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: 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: 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: 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
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: 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
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: 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: 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: 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: 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
Re: Perl6 perlplexities [was: "Re: $1 change issues..."]
On 11/7/05, Michele Dondi <[EMAIL PROTECTED]> wrote: > On Fri, 4 Nov 2005, Rob Kinyon wrote: > > > So, for a bit of extra complexity, I get peace of mind for myself and my > > users. > > The point being, and I'm stressing it once again but no more than once, > that maybe we're adding two bits of extra complexity, whereas just one bit > not only would have been enough, but would have bought you even more peace > of mind. Then again: this is a _feeling_ I got e.g. by reading the > appearently endless discussions about the specifications of sub > parameters, which seem to ensue inherent technical difficulties having to > do with the attempt _conciliate_ too many different paradigms. Honestly? I skip about 50% of the discussions on this list. I don't care about most of the syntax discussions and I don't care about sub signatures. Well, I -DO- care, just not enough to wrangle about it. All I care about is "Can I do what I want to do in an easy fashion?" That's why I spent so much time on roles and why I've released Perl6::Roles to CPAN. (Well, that was for DBI-2, but I can claim it was for me, right?) The point is that I will not use a lot of the features in Perl6, just like I didn't use alot of the features in Perl5. I doubt I'll ever use PGE directly (though macros will be nice, once I figure out where I'd use them). Same with most of the subroutine types. Though, I do find the complexity reassuring. I like having the options, even though I will never use them. The alternative is Perl5, where you can do (almost) anything you could want, except you have you jump through lots of hoops and you end up with something that works, but really really slowly. No-one wants that. Rob
Re: Perl6 perlplexities
> And when your user does want to, essentially say "Nah, you screwed up > designing > that object protocol, children shouldn't've been protected." it's the work of > a > moment to write: > >thing.send(:children, *args) I told you I'm still learning. I hadn't gotten to that part of the Pickaxe. :-/ > > (Oh, and Ruby has first-class block. W00T!) > > And continuations. But continuations are scary. Good scary, but still scary. First-class blocks make continuations and coros almost neglible to implement from an API perspective. Almost makes me wonder how much trouble it would be to implement this in P5 ... Rob
Re: implicitly doing a role
On 11/4/05, Austin Frank <[EMAIL PROTECTED]> wrote:
> Hello!
>
> 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?
>
> role Documented {
> has $.documentation;
> }
>
> class Foo does Documented { ... }
>
> # I don't know why Bar isn't declared as doing Documented
> # but it meets all the requirements of doing Documented...
> class Bar {
> has $.documentation;
> }
>
> my $baz = Foo.new( $documentation => "q to quit" );
> my $qux = Bar.new( $documentation => "enter to continue" );
>
> sub show_docs ( $obj.does( Documented ) ) { # or $obj ~~ Documented
> say $obj.documentation;
> }
>
> show_docs( $baz ); # "q to quit"
> show_docs( $qux ); # "enter to continue" -or-
> # error because Bar doesn't explicitly do
> # Documented?
>
>
> I guess we don't really need implicit doing of roles to get both of
> those objects to print their documentation, as we could have something like
>
> sub show_docs ( $obj ) {
> if ( defined $obj.documentation ) {
> say $obj.documentation;
> }
> else {
> die "Should have included a documentation string"
> }
> }
>
>
> Should roles that are implicitly done pass tests like .does and ~~ ?
> What are the reasons that they should or shouldn't?
I say no. It goes back to does a role provide a list of function names
with possible default implementations or does it provide a behavior
that is supported by a set of related functions that one can override,
if desired. What you're proposing assumes that roles are nothing more
than jazzed up Java interfaces. I would hate to see that happen. So, I
say that it should be the latter.
Rob
Re: Perl6 perlplexities [was: "Re: $1 change issues..."]
On 11/4/05, Michele Dondi <[EMAIL PROTECTED]> wrote:
> I'm still convinced my remark _partly_ applies in the sense that the
> overall impression is that a vast majority of most common needs is
> addressed by a *subset* of the current features and trying to stuff all
> them in has brought in quite a lot of discussions of which I'm not even
> sure if they've all settled down.
I think a good comparison can be made to Ruby. For work, I've been
learning Ruby this past week (we're going to try out Rails to see if
we like it). As my colleague put it, Ruby has all the P6 features we
want and it's usable now.
Ruby's OO system is 1000% more complex that Perl5's. Yet, it's still a
net win. For one thing, I don't have to write the following anymore
(lifted from a CPAN module I am working on):
sub children {
my $self = shift;
if ( caller->isa( __PACKAGE__ ) || $self->isa( scalar(caller) ) ) {
return wantarray ? @{$self->{_children}} : $self->{_children};
}
else {
return @{$self->{_children}};
}
}
This is in a vain attempt to implement a protected subroutine. In
fact, I really want a private writing accessor with a public reading
accessor, but have absolutely no way to implement that.
Why do I want such a beast? Because I want to GUARANTEE in an absolute
kind of way that, unless my user truly intended to do so, he's not
going to be able to accidentally screw up my internal state.
And, no, I don't want to use inside-out classes. They're "cool" (in
all the good and bad senses of the word), don't play well with other
P5 solutions, and STILL don't provide the necessary granularity. The
problem isn't with $object->{foo} = 3; The problem is with the
subroutines that aren't real methods with correct protection
mechanisms.
So, for a bit of extra complexity, I get peace of mind for myself and my users.
(Oh, and Ruby has first-class block. W00T!)
Rob
Re: $_ defaulting for mutating ops
> $ perl -le '$u=1; ($y=$u*=5)++; print $y' > 6 It's interesting to note that this parse (due to precedence) as ($y=($u*=5))++, not (($y=$u)*=5)++ This is important for overloaded operators (which are going to become much easier to do in Perl6). The importance arises if Perl6 allows assignment to be overloaded like Ruby does. If it does, then the two expressions aren't guaranteed to be identical as they are now in Perl5. Rob
Re: Role Method Conflicts and Disambiguation
> On Nov 2, 2005, at 9:02 PM, Jonathan Lang wrote:
> > Let's say you have this:
> >
> > role A {method foo() { code1; } }
> > role B {method foo() { code2; } }
> > role C does A does B {
> > method foo() { A::foo(); }
> > method bar() { B::foo(); }
> > }
> >
> > Should the following be valid?
> >
> > role D does C { method foo() { B::foo(); } }
> >
> > IMHO, it shouldn't, because D doesn't do B.
Additionally, D most certainly does B. That it does B through a proxy
is irrelevant. Think about it this way - if you had Surfer and Dog and
"SurferDog does Surfer does Dog", wouldn't you want to know that
"class ScoobyDoo does SurferDog" does Dog?
If SurferDog doesn't do Dog, how would ScoobyDoo do Dog?
> I think this is too restrictive, D should be able to freely
> disambiguate or override using anything it want's to. It need not be
> related at all to it's subroles.
To further expand on this, D's disambiguation of method foo() could be:
role D does C { method foo() { Completely::Unrelated::foo() } }
Rob
Re: syntax-variants, RPN (was: Re: $_ defaulting for mutating ops)
On 11/3/05, Michele Dondi <[EMAIL PROTECTED]> wrote: > On Wed, 2 Nov 2005, Ruud H.G. van Tol wrote: > > >> http://www.nntp.perl.org/group/perl.perl6.language/17556 > > > > I understand that Perl6 allows blocks with changed/enhanced syntax, so > > it is or will become possible (to add it) as if it was in the core > > language. > > Do I understand that right? Something as simple as a 'use RPN' in a > > block? (assuming that someone created such an RPN-pre-processor > > or -compiler) > > Indeed this is what that we all know. Of course the possibility of doing > so will depend on the possiblity of building up suitable RPN syntax > consistent with the rest of the syntax. If Perl6 is parseable by Perl6, then wouldn't you be able to completely throw out the default Perl6 syntax and create your own, completely unrelated syntax? I don't know ... maybe you have PGE::Ruby that would throw out the P6 grammar and give you Ruby's grammar within the block. Then, it's just a matter of describing what PGE::RPN does - what it adds, what it removes, and what it modifies. In my opinion, if you use a grammar extension, ALL bets are off within that scope until you've read the documentation. Literally anything and everything can happen, if the author deemed it so. It's a source filter-like construct that doesn't suck because source filter-like constructs are part of the spec. Rob
Re: $_ defaulting for mutating ops
On 11/2/05, Michele Dondi <[EMAIL PROTECTED]> wrote: > On Fri, 28 Oct 2005, John Williams wrote: > > > But IMHO the reduction in typing for this relatively minor issue is not > > really worth the surprise to newbies at seeing operandless operators. > > I don't buy that argument as newbies are already exposed to all sorts of > surprises including operandless operators. Including mutating operandless > operators. What is s/// after all? Or is there a good reason for an > asymmetry between different classes of operators? I think the difference comes from the Principle of Least Surprise. The various operators being discussed in this thread are all operators which are in languages that have common use - C, C++, Java, the .Net stack, etc. Regexen and the various built-ins are generally considered to be Perl-specific, so if they're weird, this is just a Perl-ism. The PoLS doesn't apply. Yes, from a consistency point of view, ALL operators should default to $_ or some other sensible item ($*STDIN for <>, etc). However, the PoLS does need to guide our decisions. Rob
Re: Role Method Conflicts and Disambiguation
On 11/1/05, Jonathan Lang <[EMAIL PROTECTED]> wrote: > Rob Kinyon wrote: > > > 1. choose one of a set of available methods to call its own. > > > 2. create a version of its own. > > > 3. pass the buck. > > > > #1 and #2 are identical. Stevan and I have always viewed #1 as a > > special case of #2. If you want to choose a method to call, then > > create a method of your own and have it wrap the one you want to call. > > > > The benefit here is that you can do more than just pick a method. > > Let's say that you have a conflict and the correct behavior is to do > > them all, but in a certain way. Or, maybe the correct behavior is to > > provide a limited API over one version. > > > > Maybe, there'll be some sugar to allow #1 to be its own syntax, but it > > should be viewed as a #2. > > You're right. But this obscures the point that I was trying to make: > we need to decide what set of methods are available when > disambiguating. Is the DOESA list public or private? Should the role > be able to look up any public method that any of its ancestors have, > or should it be restricted to just the methods that its parent roles > have? Given the flattened nature of composition, I feel that the > latter is more appropriate. Actually, given the flattened nature of composition, any role should have access to -every- method that a class would be given through doing that role. So, the DOESA list should be all the public methods that the role is acting as a gateway for. Rob
Re: Role Method Conflicts and Disambiguation
> 1. choose one of a set of available methods to call its own. > 2. create a version of its own. > 3. pass the buck. #1 and #2 are identical. Stevan and I have always viewed #1 as a special case of #2. If you want to choose a method to call, then create a method of your own and have it wrap the one you want to call. The benefit here is that you can do more than just pick a method. Let's say that you have a conflict and the correct behavior is to do them all, but in a certain way. Or, maybe the correct behavior is to provide a limited API over one version. Maybe, there'll be some sugar to allow #1 to be its own syntax, but it should be viewed as a #2. Rob
Re: Role Method Conflicts and Disambiguation (Theory-theoretic take)
On 10/28/05, Luke Palmer <[EMAIL PROTECTED]> wrote: [snip] > It was the fact that at each stage of the game, we summarized the > defaults and requirements for each role, ignoring the internal makeup > (i.e., what roles were composed into it, etc.). So, in theory, one should be able to ask any given role "What do you provide?" as well as "What do you require?". (I'm not saying that the syntax should be available, but that the information to answer those questions should be easily calculable.) One concern I have is that I would like to believe that a role is a "group of related behaviors that provides a functionality." So, if Foo does roleA and I as the user of Foo asks "Do you do roleA?" and it replies "Yes," then I can make some assumptions about Foo's functionality. Otherwise, this devolves into interfaces. Interfaces suck, especially given as they're limited to naming. Now, if we were to say that all roles, by default, provide multimethods, then conflicts only occur for methods that have identical dispatching semantics. At that point, it's truly a conflict and would need to be resolved by the composer (whether that's a role or a class). Now, it's obvious why a class would have to resolve that conflict. I would say that a role would have to resolve the conflict is that a role should present a consistent API to the rest of the world. In other words, I want to be able to depend on the fact that classA does roleAB means something in terms of the functionality that classA provides to me. I don't want it to be a glorified can() check. That does no-one any good. Rob
Re: Role Method Conflicts and Disambiguation
On 10/28/05, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> Roles can hold instance data that will be composed into a class. What
> I'm saying is that if you have two roles:
>
> role X { has $:foo; }
> role Y { has $:foo; }
>
> And a class that's composed of them:
>
> class Xy does X does Y { ... }
>
> That there will not be two slots for $:foo in Xy, but only one.
>
> But, I'm probably wrong about this as the X role may have methods that
> use $:foo in one way and the Y role may have methods that use $:foo in
> some other, incompatible way, so perhaps there will be a conflict just
> as when there are 2 methods of the same name.
The solution I proposed to Steve is somewhat involved, so let me take a moment.
In my view of objects, there are only behaviors. An attribute is
simply a behavior that will store some value (somehow) when asked and
will return the last value stored (somehow) when asked. The whole
concept of the attribute is to support behaviors that are (ultimately)
used publicly. Hence, from a strict encapsulation POV, the attributes
should be private to the definer.
As such, a role would have private methods that can only be called by
methods defined within that role (stubs aside). Stuff that composes
said role into themselves would only be composing the public API, not
the private API. Those methods that get composed would be able to
access the private methods (attributes or not) that were defined
within the role.
If this solution were to be enacted, then the role wouldn't pollute
the class's attributespace with its attributes and there couldn't be
any conflict between roles or the roles and the classes. This also
extends to attributes and inheritance - the private concept that C++
has. (I don't agree with the protected concept, but private vs. public
is good.)
Doing it any other way leads to the following: if A does rA and B isa
A and B defines an attribute that conflicts with the one provided by
rA, how on earth is that supposed to be detected? Especially given
that the inheritance tree of a class can be modified at runtime.
Rob
Re: $_ defaulting for mutating ops
> But IMHO the reduction in typing for this relatively minor issue is not > really worth the surprise to newbies at seeing operandless operators. AMEN! Rob
Re: Roles vs. Classes (was Re: Ways to add behavior)
On 10/27/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 27, 2005 at 05:37:13AM -0400, Rob Kinyon wrote:
> : Will I be able to do something like:
> :
> : package Foo;
>
> Hmm, you just started in Perl 5 mode.
>
> : $*VERSION = 1.3.2;
>
> Perl 5 would get confused here, so I'm presuming Perl 6. But Perl 6
> isn't likely to let you override the global run-time Perl version.
>
> : use Foo-1.3.1;
>
> That I think I understand.
>
> : role My::Foo { does Foo; ... }
>
> Okay, My::Foo does Foo here. Presumably it must "do" the Foo alias
> that the use just installed. And presumably the Foo you just used
> is a role that can be "done". Certainly you can't "do" the global
> package Foo, assuming that's what your original package declared.
>
> : alias My::Foo -> Foo; # Or whatever the syntax should be
>
> I have no clue where you're intending to install that alias.
> Are you trying to install a *Foo alias? A bare Foo is going to first
> find the local alias to the Foo you used, and that hides the global
> Foo that it would have found otherwise. I suspect you're trying to
> say
>
> *Foo := My::Foo;
>
> : And, in my other code, "use Foo;" will DWIM?
>
> I don't know quite what you mean, so I don't know if it'll do what
> you mean. If you're trying to establish a policy that defaults a
> particular name to a particular version, the library interface will
> probably give you a more straightforward way to set that up.
Sorry. I'm not up on the syntax. I should do some serious backlog reading.
What I'm trying to do is load role Foo 1.0, have My::Foo do Foo, then
call My::Foo version 2.0 of Foo so that anyone else in my program will
see My::Foo instead of the original Foo. Is this possible?
Rob
Re: +$arg changed to :$arg
On 10/27/05, TSa <[EMAIL PROTECTED]> wrote: > HaloO, > > Larry Wall wrote: > > > : Yes, and dispatch as a runtime keyed access into a code multitude. > > : The covariant part of the method's sig! The code equivalent to keyed > > : data access into hashes. > > > > Um, yeah. Won't play in Peoria, though. > > Where or what is Peoria? It's an expression in the US. Peoria is a town in the state of Illinois. It has a reputation for being conservative and a "keeper of American Values" (whatever that means). So, when you say something "won't play in Peoria", you're saying that it's unlikely to be accepted by the masses. Rob
Re: Roles vs. Classes (was Re: Ways to add behavior)
On 10/26/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 26, 2005 at 07:35:05PM -0700, chromatic wrote:
> : On Wed, 2005-10-26 at 21:58 -0400, Rob Kinyon wrote:
> :
> : > Plus, the argument is a straw man. Instead of:
> : >
> : > class Some::Class is also {
> : > }
> : >
> : > you would do:
> : >
> : > class My::Version {
> : > does Some::Class;
> : > }
> : >
> : > Problem solved.
> :
> : Don't forget the fun of modifying all existing uses of Some::Class to
> : use My::Version instead, if that's even possible.
>
> That should mostly be handled by virtualized class names.
Will I be able to do something like:
package Foo;
$*VERSION = 1.3.2;
use Foo-1.3.1;
role My::Foo { does Foo; ... }
alias My::Foo -> Foo; # Or whatever the syntax should be
And, in my other code, "use Foo;" will DWIM?
Re: Roles vs. Classes (was Re: Ways to add behavior)
On 10/26/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
[snip]
> Okay, an open class means you can add methods to it, right? So, let's
> say you have this class:
>
> class Foo {
> method foo() {...}
> method bar() {...}
> }
>
> And this code:
>
> my Foo $x = Foo.new;
> $x.foo();
> $x.bar();
>
> This might be compiled to the following pseudo intermediate code:
>
> my $x = Foo[0]();
> Foo[1]($x);
> Foo[2]($x);
>
> Now let's say you extend the class:
>
>class Foo is also {
>method baz() {...}
>}
>
> Is there any reason that the preceding pseudo intermediate code is no
> longer valid? I don't see one; baz() is just installed in slot 3. So
> why would you say it was faster to have it closed?
What about:
class Foo is also {
method foo() { ... }
}
Where the second foo() is no longer what the first foo() did.
Furthermore, let's say you have:
class Bar isa Foo {
method floober() { ... }
}
If they were roles, then role Bar could alias all the methods it
inherits from role Foo. In other words, it can cache all the method
lookups at compile-time. That's a substantial savings. If they're open
classes, the runtime has to throw out all the cached lookups the
moment any of the classes upstream are modified.
Plus, the argument is a straw man. Instead of:
class Some::Class is also {
}
you would do:
class My::Version {
does Some::Class;
}
Problem solved.
Rob
Re: Roles vs. Classes (was Re: Ways to add behavior)
On 10/26/05, chromatic <[EMAIL PROTECTED]> wrote: > On Wed, 2005-10-26 at 20:29 -0400, Rob Kinyon wrote: > > > I would prefer to use roles as they're closed by default, leaving > > "class" to be my powertool, if I need the power. > > I don't understand this desire; can you explain your reasoning? If a role is an immutable class, that means that its internals cannot be changed. Hence, the compiler can trust that it will be the same at the end as at the beginning. Which means it's optimized. Which means my objects run faster if I create them from roles than if I create them from classes. And, given that this seems to be the sole difference between them (mutability vs. immutability), why would I use classes as my standard? Rob
Roles vs. Classes (was Re: Ways to add behavior)
> : 3) Aren't classes mutable and roles immutable by default only? Or has > : this changed? > > Of course. To change the default for a role, call it a class, and > to change the default for a class, call it a role. :-) Does this mean that roles are the recommended way to create immutable classes? Given that roles and classes now seem to differ only in their mutability, I can't see a reason why I would use class as my default object definer. I would prefer to use roles as they're closed by default, leaving "class" to be my powertool, if I need the power. Rob
Re: Ways to add behavior
> So maybe we can define our terms like this: > > type: a completely generic metaterm for any of the following, > and then some. > > class: a mutable interface object that manages instances in the > "classical" way, with covariant derivational properties. > > role: an immutable and possibly generic interface class, with > covariant compositional properties. > > kind: the abstract, often unnamed type of an actual instance > or storage location, abstracted from any of its machinery or > degree of definedness. You should not generally declare a "kind", > they just happen. > > subtype: a potentially contravariant type based on any of the > previous types, allowed to impose constraints that are more > selective than a kind is allowed to be. > > Then ^T $x binds T to the kind of $x. And $x.kind == $y.kind asks > if two objects are of the same type, but $x.kind isn't a class-like > object, only an identity of some sort. $x.meta returns the Class > instance, or whatever. A few questions: 1) Where does prototype-style OO fit into all of this? I hope it's not through repeated eigenclasses (or whatever they're called this week) ... that just sounds too heavy. 2) Isn't Dog|Cat kinda declaring a kind? Thus, can't you say "my Dog|Cat $catdog;" and be talking about a kind? I would think that a "named kind" is just a role ... 3) Aren't classes mutable and roles immutable by default only? Or has this changed? Rob
Re: Ways to add behavior
On 10/26/05, Stevan Little <[EMAIL PROTECTED]> wrote: > > On Oct 26, 2005, at 12:05 PM, Larry Wall wrote: > > Of course, there are other words that are somewhat synonymous with > > "class", Unfortunately "sort" is already hosed. Maybe "kind". > > Actually "kind" is used in the "Core Calculus for Metaclasses" paper > which I brought to the hackathon (not sure if you got to read it or > not). Here is a link: > > http://research.sun.com/projects/plrg/core-calculus.pdf > > They present an rather interesting view on things, that the > definition of the instance creating portion of a "class" should be > seperated from the "class" or "kind" portion of the class. Actually > the first metamodel prototype grew out of an implementation of the > model they describe in the paper. This might dovetail quite nicely into the discussion of how types are now sets instead of junctions. Objects are now a junction of the various kinds that were used to create it. Thus, boxed types are now almost trivial to implement ... ? Rob
Re: Ways to add behavior
> That's just self.meta.add_method($label, $method) by my lights. > A .meta already implies/ignores the .class coercion. If we are to > support prototype-based programming $x.meta *must not care* whether > it has been given a class or an instance or something in between. > What I am calling a "class" here is basically that portion of the > current instance that is the same for all members of its class. > And that common information presumably includes information on what to > do if a method is called that is not directly recognized by the object. > Class-based and prototype-based systems have different answers to that, > but they have something in common, and I'd like to abstract that out > and call it something. I've been calling it "class", but maybe I > should call it something else to avoid confusion. A "type" maybe. > That would imply that ¢ is really a "type" variable rather than a class > variable. But maybe "type" is too overloaded already. But maybe not. I'd like to take this moment and point to my somewhat hand-wavy metamodel proposal from last week. When Stevan and I were talking about this, we called it a "quark." "Atom" also works quite nicely, but quarks are cooler. Plus, if you think about the definitions that go into creating an instance (class, role, prototype, etc), it makes sense that if the instance is the smallest indivisible thing there is, then the things that go about being its definition are the quarks. > Anyway, if my "class" turns into "type" or something else, maybe I > can be persuaded to go with ^T instead of ¢T. Q(T) ? :-) Rob
Re: new sigil
> And in fact, its very existence defies another implicit principle of > mine, that is, the "principle of partial definition": Defining a new > type or instance can only break a previously typechecking program by > making it ambiguous. The idea behind that is that at some time you > may realize that oen of your types already obeys another type, and > declare that it conforms to that interface. But you don't go the > other way around, undeclaring that an interface holds, without your > program having been erroneous in the first place. Declaring that a > new interface holds (so long as it actually does) shouldn't break > anything that was already correct. > > The principle also has strong implications with library code: > including a new library but doing nothing with it shouldn't start > randomly breaking stuff. (Unless, of course, it breaks the rules and > does crazy stuff, in which case anything goes) Is this better expressed as side-effect-free programming or loose coupling/tight cohesion? Rob
Re: Perl 6 fears
On 10/25/05, Luke Palmer <[EMAIL PROTECTED]> wrote: > On 10/24/05, H.Merijn Brand <[EMAIL PROTECTED]> wrote: > > On Mon, 24 Oct 2005 11:49:51 -0400, Joshua Gatcomb <[EMAIL PROTECTED]> > > wrote: > > > FEAR: Perl6 internals will be just as inaccessable as p5 > > > > paradox. Many people don't find perl5 inaccessible at all > > Who? Do you know anybody who hacks the regex engine? japhy. Though, granted, he's on a whole new level of insanity. Rob
Re: new sigil
> Basically, ¢T is a close analog of &t, which is the variableish form
> for "sub t". When used in a declaration, both of them introduce a
> bare name as an alias into whatever scope the declaration is inserting
> symbols, albeit with different syntactic slots. So just as
>
> my &t := { ... }
>
> introduces the possibility of
>
> t 1,2,3
>
> so also a
>
> my ¢T := sometype();
>
> introduces the possibility of
>
> my T $x;
I'm assuming that when you allow
my ¢T := sometype();
you're also allowing
my class T := sometype();
So, what happens when stupid me names a class "class" through
symbol-table craziness?
Rob
Re: $_ defaulting for mutating ops
On 10/25/05, Juerd <[EMAIL PROTECTED]> wrote:
> I think it'd be great if +=, ~=, +&=, ++, etc, could all assume $_ on
> their LHS when there is no obvious operand.
>
> This clashes with &prefix:<=>, but that's nothing a space cannot fix.
> Same for lvalue subs called x or xx (or X or XX).
>
> my $subject = "foo foo foo";
> given ($subject) {
> s/foo/bar/; # "bar foo foo"
> ++; # "bar foo fop"
> x= 2;# "bar foo fopbar foo fop"
> ~= "!"; # "bar foo fopbar foo fop!"
> }
>
> Especially bare ++ would be useful, I think.
Did you post this specifically to anti-address the fear that P6 will
be more line-noise-ish than P5? :-p
Rob
Re: Perl 6 fears
On 10/24/05, Nate Wiger <[EMAIL PROTECTED]> wrote: > Joshua Gatcomb wrote: > > On 10/24/05, Juerd <[EMAIL PROTECTED]> wrote: > > > Feel free to add your own, or fears you heard about! > > > > FEAR: The Perl6 process is driving away too many good developers > > > > FEAR: Perl6 will not be as portable as p5 > > > > FEAR: Perl6 is un-necessary and the time, money, and resources is impacting > > p5. > > These are at the top of my list. Sooner or later big Perl advocates > (like myself) are going to look for other languages because the future > is too uncertain and unstable. > > Also, in terms of module rewriting: This is a massive effort. I don't > know if anybody's looked at the internals of stuff like Class::DBI and > its derivatives, but it's huge. I have. Module rewriting should be look at in terms of implementing something completely new to fit the current spec, at least in the beginning. Modules like CDBI are good because they have a lot of tests. So, you run the tests in P5 and have them access the P6 classes. Add new tests to test new P6-only features, like roles, and you're good to go. You don't need to read the internals to port the module. Plus, rewriting is going to happen over the space of 1-2 years, which is just fine. Remember, there's still Perl4 code out there, and that was over 10 years ago. In 10 years, there will still be Perl5 code out there, and it will run just fine on Parrot (and whatever other VMs are out there). This is the point I think you're missing - you can write pure native Perl5 in a Perl6 environment and call Perl6 modules, without a single issue. You can call Perl5 modules from Perl6 without a single issue. Everything else is icing. > The fact that there's not alot of active p5p'ers on this list should > alarm people more. Why? They're focused on Perl5, not Perl6, as it should be.
Re: Perl 6 fears
On 10/24/05, John Macdonald <[EMAIL PROTECTED]> wrote: > On Mon, Oct 24, 2005 at 02:47:58PM +0100, Alberto Manuel Brandão Simões wrote: > > Another is because it will take too long to port all CPAN modules to > > Perl 6 (for this I suggest a Porters force-task to interact with current > > CPAN module owners and help and/or port their modules). > > I think Autrijus has the right idea that Perl 5 CPAN modules > should just work in Perl 6 without change. > > Just as Perl 6 is the community rewrite of Perl 5, moving > a module from CPAN to 6PAN should not be done as a hasty > make sure everything is moved over kind of event, but rather > should be done as a way of choosing the best features out of > the various Perl 5 modules on CPAN and peoples merging in the > experience people have gained from using them as well as the > experience people gain from *using* Perl 6. > > So, that is both good news and bad news - the good news is that > CPAN will be just as useful for Perl 6 right from the start; > the bad news is that the community rewrite of CPAN won't > happen overnight but could take as long for CPAN as it did > for Perl 6. (In fact, depending upon how you measure it, it > will take longer because some modules will never be rewritten, > but of course, those will be the modules that no-one feels a > sufficiently pressing need to rewrite; while for other modules, > the Perl 5 CPAN version will fit in well enough that there > is no urgency to convert it, even though it is being used, > until a few years done the road a rewrite allows additional > Perl 6/6PAN capabilities to be merged in.) I see modules being ported for a few reasons: 1) The module needs to be written in native P6 so that what was in XS now targets Parrot or the P6 grammars 2) Features are either easier or just plain old possible with P6. 3) The class is better written as a role. For example, having CGI written in Parrot ASM would be very nice. Having CGI written so that it's not as crufty would also be really nice. DBI being native P6 would be good. DBD's being roles that a DBI object does would be really nice. Rob
Re: Avoid the Yen Sign [Was: Re: new sigil]
On 10/23/05, Autrijus Tang <[EMAIL PROTECTED]> wrote: > Dan Kogai wrote: > > To make the matter worse, there are not just one "yen sign" in Unicode. > > Take a look at this. > > > > ¥ U+00A5 YEN SIGN > > ￥ U+FFE5 FULLWIDTH YEN SIGN > > > > Tough they look and groks the same to human, computers handle them > > differently. This happened when Unicode Consortium decided to make BMP > > round-trippable against legacy encodings. They were distinct in JIS > > standards, so happened Unicode. > > In addition to your handy table, the >> and << french quotes, which are used > quite heavily in Perl 6 for both bracketing and hyper operators, also have > full width equivalents: > > 300A;LEFT DOUBLE ANGLE BRACKET;Ps;0;ON;Y;OPENING DOUBLE ANGLE BRACKET > 300B;RIGHT DOUBLE ANGLE BRACKET;Pe;0;ON;Y;CLOSING DOUBLE ANGLE BRACKET > > Half width: «» > Full width: 《》 > > There is no way to type out the half-width yen and double angle brackets under > MSWin32, under either the traditional or simplified code pages; only full > width > variants are available. > > One way to approach it is to make Perl 6 accept both full- and > half-width variants. > > Another way would be to use ASCII fallbacks exclusively in real programs, and > reserve unicode variants for pretty-printing, the same way that PLT Scheme and > Haskell recognizes λ in literatures, but actually write "lambda" and > "\" respectively > in everyday coding. Isn't this starting to be the question of why we have the Unicode operators instead of just functions? Would it be possible to have a function be infix? Rob
Re: Slightly OT: zip() for Perl5?
Does TYE's Algorithm::Loops's mapcar() provide the basic functionality of what you're looking for? Rob On 10/21/05, Mark Reed <[EMAIL PROTECTED]> wrote: > Is there a CPAN module which provides the functionality of ¥/zip() for > Perl5? I don't see anything obvious in the Bundle::Perl6 stuff. Not hard > to write, of course, just wondering if it's been done . . . > > > >
Fwd: $1 change issues [was Re: syntax for accessing multiple versions of a module]
Feh - I really need to get on gmail's case for providing a keystroke for "Reply to All". Rob -- Forwarded message -- From: Nate Wiger <[EMAIL PROTECTED]> Date: Oct 21, 2005 2:38 PM Subject: Re: $1 change issues [was Re: syntax for accessing multiple versions of a module] To: Rob Kinyon <[EMAIL PROTECTED]> Rob- >>BTW, C and PHP both use -> "still". > > That's because PHP is a Perl templating engine that got too big for > its britches. (http://www.devshed.com/c/a/PHP/An-Introduction-to-PHP/) Hah, that's a funny way to look at it. Although, PHP forked back in 1997, reading the article. There's alot of stuff it does differently nowadays, some better, some worse. >>Anyways, you can listen or not listen to those of us from real, large, >>corporate environments. I'm just trying to temper the enthusiasm for >>many of the real improvements in Perl 6 with some of the real costs - >>which are largely being ignored as "no big deal". > > I think YOU forget that nearly everyone else on this list, including > @Larry, has worked in large corporate environments. My understanding > of the response has been "Yes, there might be issues. They are all > solveable with a little elbow grease." And, frankly, you can run every > P5 program under Perl6. I'm not seeing what the problem is. Fair enough. Maybe I'm just a whiner. That's possible. But, I'm on the cusp of a major new outing, namely [snip]. The point is, I don't like the idea of having to relearn a ton of stuff midway thru the 5+ year product cycle of [snip]. So I'll probably end up choosing a different language for the team to use, which is too bad. -Nate P.S. I didn't post this to the list, because you didn't
Re: new sigil
> > So, you are proposing that the Perl of the Unicode era be limited to > > ASCII because a 15 year old editor cannot handle the charset? That's > > like suggesting that operating systems should all be bootable from a > > single floppy because not everyone has access to a CD drive. > > I saying that, since my up-to-date version of vi on my up-to-date OpenBSD > can't type, much less even allow me to paste in, a Latin-1 character, this > is an issue. You're still using the base vi vs. vim?!? I didn't know people did that when it wasn't 3am on Sunday when trying to fix a borked /etc ... Huh! Rob
YAMM (Yet Another MetaModel)
I'd like to propose a new metamodel that (I hope) will meet all the specs @Larry has stated thus far. This metamodel is in two parts. Part the first: There is a single object given to P6 called Factory. (No, Steve, there are no turtles.) Factory has two behaviors, no state, and no classes. The behaviors are: * create() - this will create a blank object with no behaviors or state. * set_behavior( $object, $name, $behavior) - this will assign $behavior to $object callable by $name. Part the second: A set of keywords will be used to generate objects. That set of keywords would include class and role. These objects do not have classes - they are -things- in their own right. (Still no turtles, Steve.) class and role, for instance, would be given the behaviors: * new() - the "constructor". This wraps Factory.create() and Factory.set_behavior() appropriately. It's unclear whether each item new() creates should have the methods within them or aliases to the class's methods. * eat() - this would support composition through "has" * clone() - maybe? Plus, whatever other behaviors is necessary. The keyword "is" would be handled by adding in state (which is just a behavior wrapping some data) to handle method redispatching to another object (the parent class). Yes, this is very prototype-ish. But, the metamodel that Steve's been working on is moving in that direction. Everything is an object already. Let's just clear some of the cobwebs and provide a truly clean interface. Rob
Re: new sigil
On 10/21/05, Steve Peters <[EMAIL PROTECTED]> wrote: > On Fri, Oct 21, 2005 at 02:37:09PM +0200, Juerd wrote: > > Steve Peters skribis 2005-10-21 6:07 (-0500): > > > Older versions of Eclipse are not able to enter these characters. That's > > > where the copy and paste comes in. > > > > That's where upgrades come in. > > > That's where lots of money to update to the next version of WSAD becomes the > limiting factor. So, you are proposing that the Perl of the Unicode era be limited to ASCII because a 15 year old editor cannot handle the charset? That's like suggesting that operating systems should all be bootable from a single floppy because not everyone has access to a CD drive. Rob
Re: new sigil
> Surely you aren't suggesting that these non-English speakers do not have > access to the ASCII (or EBCDIC) character sets for their editors, are you? Surely you aren't suggesting that your editor doesn't have access to the Latin-1 charset, are you? Let's take a look at popular editors: vi - check emacs - check eclipse - check mutt - check (http://www.rano.org/mutt.html) Notepad - check A bazillion other editors - check (http://www.alanwood.net/unicode/utilities_editors.html) > I have worked on an app that needed to work with English (US and GB), > German, and Japanese. I do not, however, remember having to write my > code in anything but ASCII. No, I had to edit my -templates- and -data files- that included French text. Some of them could use HTML entities, but the datafiles intended for the DB couldn't. > As I mentioned earlier, most programmers in a corporate environment have > limited access to system settings. Changing them in some cases can cause > reprimands or dismissal. Systems are often set up with the bare minimum > of locales and character sets necessary to do the job. Also, you have to > deal with the situations where programmers are connecting to *nix servers > through a variety of Windows-based XWindows servers (Exceed, Cygwin, etc.) > complicates what character sets are available immensely. I have worked as a contractor in almost a dozen settings, most of them corporate lockdowns, and I've always been able to go to my manager and say "To be more productive, I need this tool" and it would be loaded the next day. The few times I've had to talk to an IT person to explain the tool, I'd do it over lunch (my treat) and it would be on my desktop the next morning. Saying you cannot get a tool you need loaded on your machine is, essentially, saying that you cannot play corporate politics. I'm assuming you can, which means this is a straw man. Rob
Re: new sigil
On 10/20/05, Steve Peters <[EMAIL PROTECTED]> wrote: > I have some serious concerns about using Latin-1 sigils within Perl 6 and > the ASCII multi-character aliases. Am I not understanding something that > I should see this as an advantage? I had the same concern a few months back. I've come to see the light in this fashion: 1) more and more Perl programmers come from non-English countries. Heck, the Pugs effort is at least 50% non-US, if not more. None of the are on US soil and very few of the leaders are US citizens. 2) More and more of us are programming with internationalization (i18n) in mind. Just recently, I had to edit french text within the templates of an app I work on. If you haven't already, you will be doing so in the near future, within the next 3 years. 3) Every editor (with very few exceptions) can display Latin-1 and, with a few more exceptions, can input Latin-1. If your favorite editor cannot, then that's something to bring up with the authors. Windows ... yeah. As you pointed out, the old joke goes "Doctor, it hurts when I use Windows . . . then, don't use Windows!" With the availability of dual-booting into FreeBSD/Linux (given the near-complete migration of all the necessary Office products) and both gvim and emacs having been successfully ported to WIn32, there is a way to do it. gvim on WinXP will do all Latin-1 charset with the vim keys. (I don't know about emacs, but I'd be shocked if it didn't.) If your IT department's policy is rigid, a quick discussion with your manager's manager will solve that problem immediately. Or, the cost of a few lunches with your favorite IT person will exempt your computer from the nightly audit. ($50 goes a long way ...) Personally, I plan on using every single Latin-1 operator I am given access to. All the cool kids will ... Rob
Re: syntax for accessing multiple versions of a module
> Unfortunately many people WILL have to deal with such changes, and > the question should be: Does a given change offer a clear improvement? > As you said, if we're helping %1 of people %1 of the time, are the > other 99% really going to change all their scripts? No chance. You again misread what I said. "The other 99%" aren't even going to notice the changes. Remember - 90% of all Perl code in the wild that should use hashes doesn't. 90% of all Perl code that should use map and grep doesn't. 90% of all Perl code that should use regexes doesn't. The authors of those programs aren't even going to notice that P6 changed. All they're going to see is that there's a few VERY MINOR syntactical changes, they'll adjust, and they'll be happy. Please remember the primary uses of Perl5 - systems administration, package management, and CGI scripts. By far, those are the overwhelming uses of Perl. In fact, I would argue that 99% of all Perl code in the world falls under those three categories. If you don't believe me, read "The Pragmatic Programmer". These are excellent programmers and their view of Perl is for: 1) Writing tests (pp. 53, 197) 2) Project management and glue (pp. 100-101) In fact, they specifically state in Tip 28 that every programmer should learn a "Text Manipulation Language" (the authors prefer Ruby and Perl) in order to do these things. These are "The other 90%" you refer to. They're not going to care one way or the other. And, if they do, /usr/local/bin/perl won't suddenly disappear like Cindarella at the ball, you know. Rob
Re: syntax for accessing multiple versions of a module
On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote: > And, it shares alot with other languages people know and use. That's more because languages are incestuous (like Perl) instead of languages independently arriving at the same conclusions. Yes, the "while" loop is going to look the same everywhere. But, the fact that everyone uses $1 to mean the first match has nothing to do with whether or not that's a good idea. The first engine did so, which means the next one probably will. > Right now the design is going towards something that's very very > un-Perlish from a syntax standpoint. Sure, the philosophy's there, but > there are fewer and fewer things Perl 6 shares with Perl 5 (or other > widely-used languages). I wholeheartedly disagree. You can take any piece of P5 code and, with very few modifications, have it run as native P6 code. You won't be using a ton of the greatest features, but we have that in P5. I once taught a programmer who'd been using Perl for over a year how to use hashes. I have an article coming up in early November on perl.com about how and why to use subroutines. Just because _you_ know about the feature doesn't mean the hoi-polloi do. Heck, I've been programming in Perl for almost 10 years and I have NEVER written a line of XS. I wouldn't know where to start. Frankly, most of the features in P6 look to be usable by 1% of the Perl developers, and then only about 1% of the time. Most of my P6 is going to be very vanilla. I'll take advantage of most of the new list operators and thoroughly abuse the class/role system, but I'm not going to be writing my own grammars or deal with $0/$1/etc. I don't deal with them now - I prefer named captures. The point is that if you want to truly clean off the cruft, you have to approach with a completely open mind. That open mind is going to piss off a lot of people and you will never do everything you were hoping to do, but the end product will be better off for it. You'll never reach the moon unless you shoot for the stars. Rob
Re: syntax for accessing multiple versions of a module
On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote: > Larry Wall wrote: > > I think there can be some kind of community metainformation that sets > > defaults appropriately. And if not, the site/project can certainly > > establish defaults. On the other hand, a lot of projects do simply > > want to specify the version and author explicitly eveyr time, > > and they'd rather tweak it by hand (or by script) if they want to > > change it, since then at least they know when they need to rerun the > > regression tests. > > I think it's a laudable idea in theory, but not necessarily application. > I've done quite alot of Perl programming, and I've never run into this > personally. Who has? (Really, I'm being serious.) Are there really > multiple modules sharing interchangeable interfaces? Or instances where > we want to allow the same name to mean different concepts depending on > the author? Please see http://www.perlmonks.org/?node_id=501496 for more on the issue of names. My Tree module and Schwern's Tree distro have almost zero interface compatibility. They both represent N-ary trees, except mine exposes the tree interface and Schwern's is just a OO interface for a hash implemented as a tree. My module is descended from Tree::Simple, except ::Simple almost never is. The same thing goes for my version of Tree::Binary and Stevan Little's. Two completely different interfaces, but here we're solving the same problem. The major difference between mine and his is that mine inherits from my Tree whereas his is an independent module. This means that adding transparent persistence (which is what my rewrite does) to his module is a bit of a bear. Hence, you might want to use RKINYON's Tree::Binary over STEVAN's Tree::Binary. Or, what should I call mine? (This is a real question - if you have any suggestions, please let me know!) > There's no logical difference between: > > use DBI:TIMB > use DBI:JEFFSTER > > And: > > use TIMB::DBI > use JEFFSTER::DBI No, this isn't any good, either. I took over DFERRANCE's PDF::Template implementation. He has nothing to do with it anymore. So, DFERRANCE::PDF::Template now becomes RKINYON::PDF::Template? Or, does RKINYON now maintain something in the DFERRANCE namespace? What on earth does the name DFERRANCE provide, except for an additional layer of confusion. > Anyways, I don't like the idea of people being able to upload > identically named modules to CPAN. I think that's a very bad idea. See > Rob Kinyon's message. I think you misinterpreted my message. My point is that uploading things with the same name is a good plan, but it has to be thought through, especially given the points I raised. But, I very much agree that it should happen. I'd like to propose a slight shift in emphasis. I think that more focus needs to be made in project-wide or namespace-wide disambiguation and module aliasing. If I was able to say in my CP6AN distro that I depend on DBI:2.05-:cpan-TIMB and that I'm going to call it DBI, then all the files in my distro should automatically have that alias built in. This means that anyone wanting to use DBI:cpan-JRANDOM in their code can alias it as DBI on a project-wide basis, yet still be able to use my distro and everything be ok. The important thing here, I think, is that while aliasing package names is a lexical action, there can be a larger lexical scope. It may be that we need the concept of a "Project", along with Module, Package, Class, and Role. This way, the Project states "Whenever you load a file that matches the criteria below, apply the following lexical _stuff_." Rob
Re: syntax for accessing multiple versions of a module
On 10/19/05, Nate Wiger <[EMAIL PROTECTED]> wrote: > My concern is that we're solving problems that don't really exist in > real-world Perl usage. Are there really two competing authors of DBI? > Or, for any product, do two people really try to market "SuperWidget"? > No, one person just changes to "SuperGadget". And with URI's, one person > gets "amazon.com". Sorry, name taken. > > I think we're actually *encouraging* problems by allowing long, clashing > names. Pretty soon all DBI modules will have to start with > > use DBI:TIMB; > > Because "JEFFSTER" decided to upload his DBI (Derivative Binary Index) > module. > > I think it will have the opposite effect of what we're trying to avoid. I'm of two minds about this, in large part because I have two experiences with the current CPAN. My first CPAN module was taking over PDF::Template, originally written by DFERRANCE. Now, it's maintained by RKINYON, soon to be maintained by RKINYON and STEVAN due to amazing contributions by AUTRIJUS (or whatever those characters are supposed to be). Now, how are authorship-changes going to be handled, particularly in the face of having two PDF::Templates out there already? Everyone is disambiguating their modules with PDF::Template-DFERRANCE vs. PDF::Template-JRANDOM. Now, they cannot upgrade to my latest feature because that requires changing every place they had hard-coded DFERRANCE. Or, will the package system map PDF::Template-DFERRANCE to PDF::Template-RKINYON? The second experience is one I'm going through right now. I was adding a feature to Tree:Simple a few weeks back and realized that it needed to be gutted to do what I needed it to do. With the encouragement of the author, I rewrote it completely. My development name for the distro is "Forest", but I have Tree and Tree::Binary as the packages. (Yeah, it's a math joke.) Except, there's two problems with that - Tree is a TLN (top-level namespace) with a lot of unrelated distros beneath it. And, Tree is owned by someone else, but that person hasn't updated Tree in 6 years. And, Tree::Binary is owned by the same guy who owns Tree::Simple. How is that going to work in P6? (For the record, I still haven't figured out what I'm going to do yet. Check Perlmonks for the SOPW in a few minutes.) Rob
Re: subclassing associated classes elegantly
On 10/19/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
[snip]
> An example of when this situation can arise is if person X implements
> a simplified XML DOM implementation using 2 classes, Document and
> Node, that work together, where one of those classes (Document) can
> create objects of the other (Node), and person Y wants to subclass
> the XML DOM implementation, meaning that those same Node objects made
> by one of person Y's Document subclass should be objects of person
> Y's Node subclass.
>
> To illustrate, say we had these 4 classes (the syntax may be wrong):
>
># This is one associated class set:
>
>class A {
> submethod one () {
>return 'hello';
> }
>
> submethod two () {
>B.four();
> }
>}
>
>class B {
> submethod three () {
>A.one();
> }
>
> submethod four () {
>return 'here';
> }
>}
>
># This is separate and optional associated class set:
>
>class C is A {
> submethod one () {
>return 'world';
> }
>}
>
>class D is B {
> submethod four () {
>return 'there';
> }
>}
>
> What I want to be able to do is set things up so that user code can
> do something that is effectively like this:
>
>my $first = A.two(); # returns 'here'
>my $second = B.three(); # returns 'hello'
>my $first = C.two(); # returns 'there'
>my $second = D.three(); # returns 'world'
>
> The situation is that classes C and D represent any arbitrary named 2
> classes that are subclassed from A and B, and so the latter can't
> know the names of the former, and the latter have to work
> independently of C and D also.
>
> This is one variant of a solution I have come up with:
>
># This is one associated class set:
>
>role AB {
> submethod name_of_class_A () {
>return 'A';
> }
>
> submethod name_of_class_B () {
>return 'B';
> }
>}
>
>class A does AB {
> submethod one () {
>return 'hello';
> }
>
> submethod two () {
>.name_of_class_B().four();
> }
>}
>
>class B does AB {
> submethod three () {
>.name_of_class_A().one();
> }
>
> submethod four () {
>return 'here';
> }
>}
>
># This is separate and optional associated class set:
>
>role CD {
> submethod name_of_class_A () {
>return 'C';
> }
>
> submethod name_of_class_B () {
>return 'D';
> }
>}
>
>class C is A does CD {
> submethod one () {
>return 'world';
> }
>}
>
>class D is B does CD {
> submethod four () {
>return 'there';
> }
>}
>
> This is another variant of a solution I have come up with:
>
># This is one associated class set:
>
>role AB {
> submethod invoke_one () {
>return A.one();
> }
>
> submethod invoke_four () {
>return B.four();
> }
>}
>
>class A does AB {
> submethod one () {
>return 'hello';
> }
>
> submethod two () {
>.invoke_four();
> }
>}
>
>class B does AB {
> submethod three () {
>.invoke_one();
> }
>
> submethod four () {
>return 'here';
> }
>}
>
># This is separate and optional associated class set:
>
>role CD {
> submethod invoke_one () {
>return C.one();
> }
>
> submethod invoke_four () {
>return D.four();
> }
>}
>
>class C is A does CD {
> submethod one () {
>return 'world';
> }
>}
>
>class D is B does CD {
> submethod four () {
>return 'there';
> }
>}
>
> In either case, the expectation here is that the submethods of role
> CD will override those of role BC regardless of which class' other
> methods invoke those, when the invocant class is C or D.
>
> So I'm wondering what is the best way to develop my associated class
> sets such that it is easiest for third parties to be able to
> subclass-extend them. Should I use one of the two solutions above
> (both of which have been tried in real life, in Perl 5, the second
> more recently)? Or is there another solution that is better than
> both?
>
> Also, in such a situation as the above, is it reasonable to support
> easy subclassing, or would it be better to avoid that complexity and
> instead expect users to create objects that wrap the others instead
> of subclassing them?
>
> Assume also that it may be counter-productive for one class to expect
> user code to invoke the second class on its behalf, such as if when
> pair of classes is hidden behind a second pair of classes that
> mediate access to them.
>
> What are some best practices here that can be used by anyone faced by
> a similar problem?
>
> -- Darren Duncan
>
[snip]
In Perl5, I would think the easiest solution would be to "trick" the
base Document class into using the right Node class.
1) Load Node.
2) Rename Node to Node::Base
3)
Fwd: top 5 list needed
> > Text-substitution macros would have to be handled in an earlier pass,
>
> I still don't see evidence for this. Or maybe I do, but I don't see
> any reason that the preprocessing pass must finish before the parsing
> begins.
Mixing C and Perl ...
my $foo;
BEGIN { $foo = '}'; }
#define OPEN {
#define CLOSE $foo
void main (void)
OPEN
BEGIN { $foo = '{''; }
printf( "I don't work\n" );
CLOSE
How does that work out? The issue is that you can interrupt the
parsing process with executable code that can affect the parsing.
That's a good thing. It doesn't work so well with text-substitution,
though. Hence, I would argue it should be disallowed.
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
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
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: 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
