Re: Definitive and Complete Perl 6 Operator List
Andrew Savige said: Is there a definitive, official, complete list of all Perl 6 operators, along with their precedence levels? I believe that Kurt Gödel, in a corollary to his famous theorem, also showed that Any Perl 6 list is either indefinitive or incomplete. Well, Synopsis 3 is the list you're looking for, but it's clearly not all there. Take the table there to be your definitive list, and mail questions about its accuracy here. I'll do my best to keep up with you and maintain it. For example, this Perl 6 program: my $i = 0; $i ~^= 2; Pugs currently rejects with: pugs: cannot cast into a handle: VInt 2 Since ~^ is string xor, I guessed that ~^= would be allowed. Yeah, any binary operator that takes two Xs to an X should have an = form. It might even be that any operator which takes an X on its left hand side and maps it to an X should have an = form, but it's probably best to keep it at the former requirement for now. Luke
Re: identity tests and comparing two references
James Mastros skribis 2005-04-01 22:48 (+0200):
$x = 42;
$a = \$x but false;
$b = \$y but blue;
$a =:= $b ???
Even without the buts, that is:
$x = 42;
$a = \$x;
$b = \$x;
I strongly believe that $a =:= $b must be false. Assignment copies! $a
=:= $b should be true only if $a and $b are the same variable
themselves, as can be accomplished by a simple $a = $b or by passing $b
as an argument to a closure somehow, like in given $a - $b { ... }.
If =:= has nothing to do with :=, it shouldn't look like it that much.
If it tests reference equality, possibly referencing non-references, it
should be spelled =\= instead, although I really question the practical
use of such operator.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Definitive and Complete Perl 6 Operator List
Luke Palmer [EMAIL PROTECTED] wrote: Andrew Savige said: Is there a definitive, official, complete list of all Perl 6 operators, along with their precedence levels? Well, Synopsis 3 is the list you're looking for, but it's clearly not all there. Take the table there to be your definitive list, and mail questions about its accuracy here. I'll do my best to keep up with you and maintain it. Uploaded so it doesn't get word-wrapped and thus rendered useless to tools: http://www.brentdax.com/junk/perl6/perl6op.txt I've included assignment forms of all operators in the exponentiation, multiplicative, additive, junctive, and tight logical levels; this may be overkill or underkill. I've not included hyper forms of these operators, as I figure they're handled by metaoperators. Also, the terms level isn't really exhaustive. In any case, let me know if anything's missing--or for that matter if anything's there that shouldn't be. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I used to have a life, but I liked mail-reading so much better.
+ or +
Bitshift, which one is it? + or + I believe only + is possible, because + has to be +«, but S03 is still inconsistent, and + comes up everywhere, including Brent's perl6op.txt. Can there please be a definitive answer, and an update to S03? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: identity tests and comparing two references
Larry Wall [EMAIL PROTECTED] wrote: : On Thu, 2005-03-31 at 23:46 -0800, Darren Duncan wrote: : : In P6, an object is a data-type. It's not a reference, and any member : payload is attached directly to the variable. Well, it's still a reference, but we try to smudge the distinction in P6. A reference as a Perl5 reference or just as a C pointer or a Parrot PMC? newclass cl, Foo # create new Foo class - 0 attributes $P0 = new Foo # make a new Foo instance $P1 = $P0 # both PMCs refer to the same object now $P1.meth()# same as $P0.meth() $P2 = clone $P0 # 2 distinct objects now $P3 = new Undef assign $P3, $P0 # same leo
Re: + or +
On Sat, Apr 02, 2005 at 12:05:37PM +0200, Juerd wrote: Bitshift, which one is it? + or + I believe only + is possible, because + has to be +«, but S03 is still inconsistent, and + comes up everywhere, including Brent's perl6op.txt. Can there please be a definitive answer, and an update to S03? The definitive answer is + -- the pod document at http://dev.perl.org/perl6/synopsis/S03.html is out of date. This has been corrected in the perl6 svn repository for some time (http://svn.perl.org/perl6/doc/trunk/design/syn/S03.pod), but I don't know the magic for getting updates in the svn repository reflected on the website. Pm
Re: Definitive and Complete Perl 6 Operator List
On Sat, Apr 02, 2005 at 01:49:24AM -0800, Brent 'Dax' Royal-Gordon wrote: : I've included assignment forms of all operators in the exponentiation, : multiplicative, additive, junctive, and tight logical levels; this may : be overkill or underkill. I've not included hyper forms of these : operators, as I figure they're handled by metaoperators. I would say that assignment operators are also metaoperators. They're just a bit picky about which precedence levels they metastasize. In other words, if someone adds an appropriate binary operator, it would automatically get the assignment meta-operator. But not if it's a chaining binary, non-chaining binary, or assignment operator. (We could define the levels that it *does* work on, but then it doesn't work on user-defined precedence levels by default. Alternatively, we could develop a profile apart from precedence levels for operators that are omitted, such as ones that return boolean values, or that create new objects, or that mutate their left argument already.) : In any case, let me know if anything's missing--or for that matter if : anything's there that shouldn't be. Seems to be missing: infix:? infix:?|. infix:?^. The shifts are all X rather than X to avoid confusion with Texas Quotes. Oh, and we recently moved = to assignment precedence so it would more naturally be right associative, and to keep the non-chaining binaries consistently non-associative. Also lets you say: key = $x ?? $y :: $z; plus it moves it closer to the comma that it used to be in Perl 5. Larry
Re: identity tests and comparing two references
On Sat, Apr 02, 2005 at 11:06:01AM +0200, Juerd wrote: : Is your view of the world like Python or like Perl 5? Them's fightin' words. :-) : Values have no identity in Perl 5. That's slightly not true, insofar as Perl 5 distinguishes hash keys by value (albeit filtered through stringification). : Containers (variables, named or : anonymous) do. That also means that even though $foo = 5 and $bar = 5, : \$foo != \$bar. In Python, with foo = 5 and bar = 5, that means id(foo) : == id(bar), but I don't like that at all. On the other hand, it would be nice to have an operator that tells you if two things would be considered the same hash thing if handed to a hash of shape(Any). That's how I think of =:=. If that's more like Python and less like Perl 5, I don't care. I'm trying to make Perl 6 like Perl 6, not like anything else. Objects are by default unique, but any particular class of objects (including value types) is allowed to define its own idea of uniqueness. Unique identity is precisely what we're looking for in a hash key, whether we stringify it or not. Larry
Re: identity tests and comparing two references
On Sat, Apr 02, 2005 at 11:22:43AM +0200, Leopold Toetsch wrote: : Larry Wall [EMAIL PROTECTED] wrote: : : On Thu, 2005-03-31 at 23:46 -0800, Darren Duncan wrote: : : : : In P6, an object is a data-type. It's not a reference, and any member : : payload is attached directly to the variable. : : Well, it's still a reference, but we try to smudge the distinction in P6. : : A reference as a Perl5 reference or just as a C pointer or a Parrot PMC? In that context, I just meant somebody's got a pointer to it somewhere, if only in the symbol table, though it could also be in a PMC. As I mentioned in a recent message, Perl 6's notion of identity is class based. Perl5 refs are not really objects in that sense of having an identity. If $foo contains a reference to something else, you have to work harder to get at the container $foo rather than object $foo points to. By default, any OO operation is going to deref it, and that includes asking it for its identity, or asking its class to compare two of its objects for identity. Does this make sense? The only application I see for typed references is to tunnel object references through some other language so that that language sees the reference as an object of its type, but if it calls back into your language, you get your original object reference back. I'd classify that as a necessary evil, but one I'd prefer to hide from stock Perl 6 programmers. Larry
Re: Documentary annotations: $what docwhy
On Sat, Apr 02, 2005 at 03:19:33PM +0800, Sam Vilain wrote:
: Luke Palmer wrote:
: Supposing I had a doc trait, could I say:
:sub f2c (Num $temp docTemperature in degrees F)
:docConvert degress F to degrees C
:{...}
: Or would I be forced to spell it doc('stuff') ?
: Well, first you need an `is` somewhere in there. And after that I think
: you'll need to do it in doc('stuff') form. If we did allow doc, then
: this:
:
: A word of warning...
:
: Perldoc[*] will eventually support this sort of thing, for sure. But it
: will lead to the unfortunate side effect that your code needs to at
: least compile without syntax errors, and without too many obscene
: mistakes - so that these traits are accessible by the dialect that
: interprets them into a Perldoc tree.
It should also be pointed out that we're making the structure of the
surrounding POD available to the code. Working from that end has
the advantage of keeping cruft out of the signature, while keeping
the information close and verifiable.
: That's if you care about seeing the information presented nicely when
: you use `perldoc Foo', of course.
If we work it out right, it won't be an either/or thing. The POD
will be easily recognizable as POD (albeit with different parsing
rules than Perl 5), but at the same time it's available as data for
introspective and class-browserly purposes.
: * - the project aiming to provide dialect-agnostic inline documentation
: for Perl 5 and Perl 6. The Perl 5 prototype is on CPAN... still in
: early stages.
If by dialect-agnostic you mean that it presents that view to
the user, that's fine. But at minimum, the project will have to be
gnostic about parsing difference between Perl 5 POD and perl 6 POD.
For example, =cut is going away, and the requirements for blank lines
are being reduced. Plus there will probably be some changes to help
the computer navigate to its associated documentation, such as tagged
fields that turn into a hash value when accessed via %=POD or whatever
the interface turns out to be.
Larry
Re: S03 problem in Hyperoperators
Aaron Sherman writes: At the beginning of the section on hyper operators, the following: The Unicode characters (\x[BB]) and (\x[BB]) should be: The Unicode characters (\x[BB]) and (\x[AB]) You should probably read S03 from: http://svn.perl.org/perl6/doc/trunk/design/syn/S03.pod from now on, as that's the one that I'll be fixing. Luke
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
On Thu, Mar 31, 2005 at 01:11:37PM -0500, Aaron Sherman wrote: : If you declare a variable to be of a type (let's even say a class to be : specific), then you have hinted to the compiler as to the nature of that : variable, but nothing is certain. : : That is to say that the compiler cannot: : : * Make any type-massaging choices yet on (implicit or explicit) : method invocations : * Issue any errors based on signature miss-matches : : Ok? Yes. You might perhaps be able to get warnings on things that look like signature mismatches, but I certainly wouldn't make it mandatory, or even the default. : Now we move on to the idea of finalization. Please correct me where I : conflate finalization and openness. I'm not sure I understand the : difference at all (no, I'm certain I don't). I think you already dug this up, but no harm in reiterating: open/closed: whether you can munge the class definition itself. final/non-final: whether this is guaranteed to be a leaf node class. : We assert (don't have the docs handy, but I'll just arm-wave the syntax) : that the class is now finalized. We don't allow assertions that a particular class is final, because that's a reversed dependency. We only allow you to assert that a particular class is non-final. One way to do that is simply to derive from it. : This means any attempt to re-define the : interface of the class is a compile-time error, correct? If we let you do it, but we don't. :-) The interface can be assumed frozen by the compiler only if the entire application requests the class finalization optimization, and if by CHECK time nobody has registered a dependency on the class by either deriving from it or claiming that they will derive from it in the future. Applications with pluggable architecture should probably not request the optimization unless there is some point in time at which it can be determined that all plugins have been linked in. : What about : changing the internals of the class (e.g. changing the code associated : with a method without re-defining the signature)? That's more like the open/closed distinction, though for an open class you could also change the interface on the fly, which would invalidate some or all of your method dispatch caches. The optimizer is also in control of open/closed classes, and you may only declare that a class must remain open. You may not declare a class closed. Again, your application may ask that all closable classes be closed. Final classes are a subset of closed classes, so if the optimizer determines that it can finalize a class but not close a class, the class is not finalized either. That's not actually a big problem, because unlike with finalization, classes may only remain open by explicit declaration of the dependency, whereas classes may be implicitly made non-final by deriving from them. This is all policy of the default metaclasses. You may, of course, have other metaclasses that establish different policies. There are applications where you probably want your classes to be born closed. This may negativly impact your ability to do AOP. : Next, what are the conditions under which a class can be finalized? : : * Can we finalize a class which has non-finalized ancestors? All ancestors are by definition non-final. : * What if it has method parameters/return values or member : variables whose types are not finalized? Depends on the extent to which we support named type equivalence vs structural type equivalence, I suppose, and whether the compiler uses type name information to make assumptions about the structure. : * What if it applies roles which are not finalized? Roles cannot be derived from, so they're always final in that sense. We should probably consider them closed by default as well, or at least closed after first use. If a role specifies implementation, it's always default implementation, so overriding implementation always occurs in a class instead. Basically, in Perl 6 I think roles take on the, er, role of finalized classes in specifying immutable interfaces, to a large extent. : Obviously each one of these questions comes with a host of what happens : if questions given a yes answer : : Another question: how does finalization interact with a class's : metaclass? Does the metaclass become a const? Is the type of a metaclass : itself a finalized class? If not, can it be finalized by user code? Metaclasses can do whatever they like. They're worse than traits, if that's possible. As I say, the default metaclass is what provides the standard policies, but they can be warped in whatever direction you like, if you want everyone to hate you. : One additional wrinkle is that *anyone* is allowed to declare a : class non-cooperative (open or non-final) during *any* part of the : compilation : : ... even after it is declared final? Can't declare anything final in Standard Perl. : Will core types be
Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]
On Thu, Mar 31, 2005 at 03:03:09PM +0200, Thomas Sandlaß wrote:
: Larry Wall wrote:
: On Sat, Mar 26, 2005 at 02:37:24PM -0600, Rod Adams wrote:
: : How can you have a level independent position?
:
: By not confusing positions with numbers. They're just pointers into
: a particular string.
:
: I'm not the Unicode guru but my understanding is that all composition
: sequences are finite and stateless with respect to everything before
: and after them in the string. Which brings me to the question if these
: positions are defined like positions in Emacs as lying *between* the
: chars? Then the set of positions of a higher level is a subset of the
: positions of lower levels.
Yes, that's how I've been thinking of them. Thanks for making that explicit.
: With defining position as between chars many operations on strings are
: downwards compatible between levels, e.g. splitting. If one determines
: e.g. an insert position on a higher level there's no problem in letting
: the actual insertion beeing handled by a lower level. With fractional
: positions on higher levels some degree of upward or tunneling
: compatibility can be achieved.
That's my feeling.
: BTW, will bidirectionality be supported? Does it make sense to reflect
: it in the StrPos type such that $pos_start $pos_end means a non-empty
: left to right string, $pos_start $pos_end is a non-empty right to left
: string and $pos_start == $pos_end delimit an empty (sub)string? As a
: natural consequence the sign indicates direction with negative length
: beeing right to left. And that leads to two times two types of iterators:
: left to right, right to left, start to end and end to start.
Offhand I'd rather have end start be undefined, I think, but I
suppose we could give it a meaning if it turns out not to be an
easily generated degenerate case like 0..-1. On the other hand,
I think right-to-left might deserve more Huffman visibility than an
itty-bitty sign that might be hidden down in a varible.
But then, we've played games with signs in substr and splice before.
It's not clear that people would want substr($x, -3) to return the
characters in reversed order, though.
: All the above leads me to rant about an array like type. Please forgive
: me if the following is not proper Perl6. My point is to illustrate how
: I imagine the future communication between implementor and user of such
: a class. Actually some POD support for extracting the type information
: into the documentation would be great, too!
:
: And yes, the :analyse should be made lazy. The distinction between the
: first and second index method could be even more specific by using
: type 'Index ^ List of Str where { $_.elems == 1 }' to convey the
: information that indexing with a list of one element doesn't result
: in a List of Str but a plain Str. OTOH this will incur a performance
: penalty and violate the intuitive notion list in, list out.
MEGO.
: class StrPosArray does Array where { ::Index does StrPos }
: {
:has Str$:data;
:has StrPos @:pos;
:
:multi method postcircumfix:[ ]
:(: Index $i ) returns Str {...}
:multi method postcircumfix:[ ]
:(: List of Index $i ) returns List of Str {...}
:multi method postcircumfix:[ ]
:(: Range of Index $i ) returns List of Str {...}
:multi method postcircumfix:[ ]
:(:Int $i ) returns Str {...}
:
:# more stuff here for push, pop, shift etc.
:
:method infix:= (: Str $rhs ) returns ::?CLASS
:{
: $:data = $rhs;
: :analyse;
:}
:
:method :analyse ()
:{
: # scan $:data for all between char positions
: # and store them into @:pos
:}
: }
:
: Question:
: does the compiler go over this source in multiple passes
: such that the declaration of :analyse is known before its
: usage in infix:=?
No, you just throw in a forward declaration with {...} in that case.
Larry
Re: use less in perl6?
On Wed, Mar 30, 2005 at 10:20:28AM +0200, Yuval Kogman wrote: : How should this stuff be expressed? 'use less' is cute, but i don't : think it really gets there. It's mostly there as a placeholder for all the true pragmas that can be ignored if you don't understand them, an idea I originally stole from Ada. We sort of got away from that notion in Perl 5, but it'd be nice if we could have some way of recognizing hints that can be ignored if unrecognized. That was the original intent of the uppercase/lowercase distinction in use, but we lost the distinction somewhere along the way. At least we've gotten rid of use overload. Maybe we can reclaim the lowercase modules for futureproofed hinting, or establish some other convention. I agree that use less ain't it. : Perhaps this interface, or it's principals should also allow : similarly controlled debugging/tracing. Usually when trying to look : inside a big app, you are only concerned about a specific part. I : think this is very analogeous to optimization hints: : : sometimes you want to override it form the command line : : sometimes you only want it to apply to calls from a certain : place : : sometimes you want to enable it from within the code it applies : to, and sometimes outside of it : : you often want a volume knob for this behavior : : you want several instances of usage to not conflict : : I'd like to see what the design team can do about this. Welcome to the design team. Have at it. :-) This problem seems to be a generalization of the earlier discussion about turning warnings on or off in lexical vs dynamic scopes. Larry
Re: New S29 draft up
On Mon, Mar 21, 2005 at 03:31:53PM +0100, Juerd wrote: In fact, won't things be much easier if shift and pop workend on strings as well as on arrays? Now that we have multis, this should be easy to do. How about defining String is Array? I don't know if I would like that, but it's an idea. Juerd -- wolverian signature.asc Description: Digital signature
Re: New S29 draft up
On Sat, Apr 02, 2005 at 11:27:09PM +0300, wolverian wrote: : On Mon, Mar 21, 2005 at 03:31:53PM +0100, Juerd wrote: : In fact, won't things be much easier if shift and pop workend on strings : as well as on arrays? Now that we have multis, this should be easy to : do. : : How about defining String is Array? I don't know if I would like that, : but it's an idea. Unfortunately it'd have to be an Array of String, since most characters these days are not fixed width, even in UTF-16. There's no reason in principle we couldn't do that, but it'd be a lot of extra overhead for most strings, and you can always split to an array explicitly if you really need that. (Plus it would only encourage people coming from C to keep thinking in C.) That being said, we will have a way of taking an array of strings and treating it as a single string for pattern matching. But there's no guarantee that the array elements correspond to individual characters unless you made it that way yourself to begin with. Larry
