Re: [svn:perl6-synopsis] r13483 - doc/trunk/design/syn
[EMAIL PROTECTED] wrote: Distinguished Set and Bag values from KeySet and KeyBag containers. Real nice. Double-you: +A CKeyBag is a CKeyHash of CUInt with default of 0. If you +you -- Affijn, Ruud
Re: [perl #40998] [PATCH] Fix build error on Win32
Ron Blaschke [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Nikolay Ananiev (via RT) wrote: # New Ticket Created by Nikolay Ananiev # Please include the string: [perl #40998] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40998 When build_dir contains spaces the build process fails. The fix is to translate build_dir to a short path name. In my opinion it would be better to escape/quote the relevant paths properly. I think the short file names were introduced for backwards compatibility, as a kludge. Besides, they are ugly to read. ;-) Ron If we use quotes, we'll have to refactor some of the scripts in the build tree, because there are many concatenations and currently they won't work if we use quotes on build_dir. There's one more way. We can check build_dir and use short path names only if there are spaces.
[svn:perl6-synopsis] r13486 - doc/trunk/design/syn
Author: larry Date: Wed Nov 29 00:25:32 2006 New Revision: 13486 Modified: doc/trunk/design/syn/S06.pod Log: you you noticed by Ruud++. Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podWed Nov 29 00:25:32 2006 @@ -1415,7 +1415,7 @@ those undefined values that do not contain an unthrown exception). A CKeySet is a CKeyHash of booleans with a default of CFalse. -If you you use the CHash interface and increment an element of a +If you use the CHash interface and increment an element of a CKeySet its value becomes true (creating the element if it doesn't exist already). If you decrement the element it becomes false and is automatically deleted. When not used as a CHash (that is, @@ -1425,7 +1425,7 @@ the actual implementation with any bits at all.) A CKeyBag is a CKeyHash of CUInt with default of 0. If you -you use the CHash interface and increment an element of a CKeyBag +use the CHash interface and increment an element of a CKeyBag its value is increased by one (creating the element if it doesn't exist already). If you decrement the element the value is decreased by one; if the value goes to 0 the element is automatically deleted. When not
Re: beg for Bag
HaloO, Jonathan Lang wrote: Note that this would mean that Seq would also have set operations. I count this as an advantage. So one can write (1,2,3) (|) (2,2,3,4,4) to get a result of (1,2,2,3,4,4). As long as the Seq is a Set, that is it has no duplicates, you get Set behavior through the Bag ops: (1,2,3) (|) (2,3,4) === (1,2,3,4); (1,2,3) () (2,3,4) === (2,3). BTW, the set/bag operations are not yet mentioned in S03 as new operators. Here's a list what I think they should be: (|) union () intersection (^) symmetric difference (/) disjoint union? (!) complement, this is difficult because you need the surrounding set (-) difference (+) join, returns a bag (*) cartesian product (**) powerset (in) membership (!in) negated membership () proper subset () proper superset (=) subset (=) superset (=) equality, also with === (!=) inequality, also with !=== Did I forget something? Regards, TSa. --
[svn:perl6-synopsis] r13487 - doc/trunk/design/syn
Author: larry
Date: Wed Nov 29 09:20:50 2006
New Revision: 13487
Modified:
doc/trunk/design/syn/S01.pod
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S03.pod
doc/trunk/design/syn/S04.pod
doc/trunk/design/syn/S05.pod
doc/trunk/design/syn/S06.pod
doc/trunk/design/syn/S09.pod
doc/trunk/design/syn/S10.pod
doc/trunk/design/syn/S11.pod
doc/trunk/design/syn/S12.pod
doc/trunk/design/syn/S13.pod
doc/trunk/design/syn/S17.pod
doc/trunk/design/syn/S29.pod
Log:
More entries in smartmatch table.
Added vim modelines to help perpetuate audreyt++'s expandtabs.
Modified: doc/trunk/design/syn/S01.pod
==
--- doc/trunk/design/syn/S01.pod(original)
+++ doc/trunk/design/syn/S01.podWed Nov 29 09:20:50 2006
@@ -161,3 +161,5 @@
into a coherent whole.
=back
+
+=for vim:set expandtab sw=4:
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podWed Nov 29 09:20:50 2006
@@ -2420,3 +2420,5 @@
Any category containing circumfix requires two token arguments, supplied
in slice notation.
+
+=for vim:set expandtab sw=4:
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podWed Nov 29 09:20:50 2006
@@ -14,7 +14,7 @@
Date: 8 Mar 2004
Last Modified: 13 Nov 2006
Number: 3
- Version: 75
+ Version: 76
=head1 Changes to Perl 5 operators
@@ -582,8 +582,10 @@
$_ $xType of Match ImpliedMatching Code
== = ==
Any Code:($) scalar sub truth match if $x($_)
-HashHash hash keys identical match if $_.keys.sort »eq«
$x.keys.sort
-Hashany(Hash) hash key intersectionmatch if $_{any(Hash.keys)}
+HashHash hash keys identical match if $_.keys === $x.keys
+HashSet members identicalmatch if $_.keys === $x
+Set Set members identicalmatch if $_ === $x
+Hashany(Hash) hash key intersectionmatch if exists
$_{any(Hash.keys)}
HashArray hash value slice truth match if $_{any(@$x)}
Hashany(list) hash key slice existence match if exists $_{any(list)}
Hashall(list) hash key slice existence match if exists $_{all(list)}
@@ -596,9 +598,13 @@
Array Regex array grep match if any(@$_) ~~ /$x/
Array Num array contains numbermatch if any($_) == $x
Array Str array contains stringmatch if any($_) eq $x
+Array Buf array equivalent to buf match if $_ eqv Array($x)
+Array Set array equivalent to set match if Set($_) === $x
+Array Any array contains item* match if any($_) === $x
Array .[number] array element truth* match if $_[number]
Num NumRange in numeric range match if $min = $_ = $max
Str StrRange in string range match if $min le $_ le $max
+Any Range in range match if $min !after $_ !after
$max
Capture Signature parameter bindingmatch if $cap can bind to $sig
CodeSignature signature compatibility* match if $_ is a subset of $x
Signature Signature signature compatibility match if $_ is a subset of $x
@@ -1699,3 +1705,4 @@
Comma is the only listop that is allowed to occur where an operator is
expected. All other listops function as a term within the list to the left.
+=for vim:set expandtab sw=4:
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(original)
+++ doc/trunk/design/syn/S04.podWed Nov 29 09:20:50 2006
@@ -985,3 +985,5 @@
to see transient variables in their current lexical scope, so their
cloning status depends at least on the cloning status of the block
they're in.
+
+=for vim:set expandtab sw=4:
Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/design/syn/S05.pod(original)
+++ doc/trunk/design/syn/S05.podWed Nov 29 09:20:50 2006
@@ -3071,3 +3071,5 @@
@array».match($regex);
=back
+
+=for vim:set expandtab sw=4:
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podWed Nov 29 09:20:50 2006
@@ -2653,3 +2653,5 @@
If a switch of the form C-abc cannot be matched against any
particular parameter, an attempt will be made to match it as if it
had been written C-a -b -c.
+
+=for vim:set expandtab sw=4:
Re: [perl #41014] [PATCH] Autobox Native Types for MultiSubs
Am Mittwoch, 29. November 2006 05:50 schrieb Matt Diephouse: It also means that string, int, and float no longer work as MMD types -- you can't distinguish between native types and PMCs. I think this is the right way to go now that we have autoboxing; I don't see any reason to differentiate. I don't think this is the best strategy. It seriously prevents all native type optimizations. While 'Integer' should be MMD-distancewise close to 'int', it should not be the same. leo
Re: [perl #41014] [PATCH] Autobox Native Types for MultiSubs
On Wed, Nov 29, 2006 at 08:49:27PM +0100, Leopold Toetsch wrote: Am Mittwoch, 29. November 2006 05:50 schrieb Matt Diephouse: It also means that string, int, and float no longer work as MMD types -- you can't distinguish between native types and PMCs. I think this is the right way to go now that we have autoboxing; I don't see any reason to differentiate. I don't think this is the best strategy. It seriously prevents all native type optimizations. While 'Integer' should be MMD-distancewise close to 'int', it should not be the same. Just to repeat my comments from #parrot, I agree with Leo that treating int as always (and only) being identical to the autobox type feels very wrong somehow. However, if we're short-term restricted to choosing between the existing implementation (where '_' doesn't match native types) and this patch (where we can't differentiate native types), I definitely want the patch. It's the lesser of the two evils. IWBNI the native types were considered in both their native and autoboxed aspects for purposes of selecting candidate MMD subs, with a match on native types resulting in a shorter MMD distance than those involving autoboxing. Pm
Re: Re: [perl #41014] [PATCH] Autobox Native Types for MultiSubs
Leopold Toetsch [EMAIL PROTECTED] wrote: Am Mittwoch, 29. November 2006 05:50 schrieb Matt Diephouse: It also means that string, int, and float no longer work as MMD types -- you can't distinguish between native types and PMCs. I think this is the right way to go now that we have autoboxing; I don't see any reason to differentiate. I don't think this is the best strategy. It seriously prevents all native type optimizations. While 'Integer' should be MMD-distancewise close to 'int', it should not be the same. What native type optimizations? Using S, I, and N registers? If using an I register is faster, wouldn't you want to unbox an Integer PMC and use an I register anyway? Is there a specific case you have in mind? -- Matt Diephouse http://matt.diephouse.com
Re: Re: [perl #41014] [PATCH] Autobox Native Types for MultiSubs
On Wed, Nov 29, 2006 at 04:43:59PM -0500, Matt Diephouse wrote: Leopold Toetsch [EMAIL PROTECTED] wrote: Am Mittwoch, 29. November 2006 05:50 schrieb Matt Diephouse: It also means that string, int, and float no longer work as MMD types -- you can't distinguish between native types and PMCs. I think this is the right way to go now that we have autoboxing; I don't see any reason to differentiate. I don't think this is the best strategy. It seriously prevents all native type optimizations. While 'Integer' should be MMD-distancewise close to 'int', it should not be the same. What native type optimizations? Using S, I, and N registers? If using an I register is faster, wouldn't you want to unbox an Integer PMC and use an I register anyway? Sure, but Parrot is unboxing for us already, without us having to do anything special: .sub 'foo' :multi(_, String) .param int abc .param pmc xyz ... .end foo(1, 'xyz') # boxes 'xyz', leaves 1 alone foo($P0, $P1) # unboxes $P0 to an int, leaves $P1 alone If I understand things correctly, specifying :multi(_, String) doesn't actually do any form of coercion, it simply says that this sub is called only if the second argument is compatible with the String type. This is true even if we have a :multi with a native type: .sub 'bar' :multi(int) .param pmc abc ## abc is an autoboxed int for us here, even though this ## sub can only be reached if the (single) argument ## is an integer register or integer constant ... .end .sub 'baz' :multi(pmc) .param string def ## Baz can only be called with a pmc argument, and that ## pmc (whatever it is) is auto-unboxed into a string register. ... .end I'm not at all an expert on the topic of multis, but it sounds to me as though :multi is being somehow conflated with when to auto[un]?box. I think :multi should limit itself to being a way of selecting which sub(s) to call, while autoboxing should be based solely on the arguments of the caller and parameters of the called sub (once that sub has been chosen by :multi). Now then, for purposes of selecting the sub(s) to call, :multi can take into account the fact that native arguments can autobox, and call a sub that specifies the autoboxed type in :multi (but preferring a sub with the native type in :multi, if one exists). And I don't think :multi should go the other way -- i.e., to assume that a boxed type will match a native type in :multi. With what I just described there's already a way to get that semantic, namely: .sub 'foo' :multi(Integer) .param int xyz ... .end With this, a foo(1) or foo($I0) call will still find the sub, but won't do any boxing or unboxing. If foo is called with an Integer pmc argument, :multi will find the sub, and the Parrot calling conventions will end up autounboxing the argument into an 'int', which is what we wanted. And if foo(...) is called with something that isn't compatible with Integer (e.g., a subclass), then :multi won't select this sub at all. But as I said, I'm no expert -- this is just my best stab at how things ought to work, at least in the short term until a more sophisticated Parrot object model is in place. And as I also indicated, I don't have nearly as strong feelings about this as I do about the fact that we need a way to specify 'any type' (including native types) in the :multi pragma. Thanks, Pm
Re: Initial feedback on PAST-pm, or Partridge
Patrick R. Michaud wrote: On Mon, Nov 27, 2006 at 09:20:08PM -0800, Allison Randal wrote: chromatic's suggestion is to replace the series of manual calls in HLLCompiler's 'compile' method with an iterator over an array of compiler tasks. I very much agree with chromatic -- indeed, this is mainly why I didn't go with putting ostgrammar methods into the HLLCompiler object before. Having HLLCompiler effectively hardcode a sequence of parser-astgrammar-ostgrammar feels a bit heavy-handed to me, almost saying that we really expect you to always have exactly the sequence source-parse-ast-ost-pir-bytecode, and you're definitely using TGE for the intermediate steps. The patch I sent is the first step toward making chromatic's suggestion work. The problem with the current implementation is that each stage decides what the next stage will be. If the PAST-to-POST transformation calls the POST-to-PIR transformation before returning, then you can't easily insert an additional stage between the two. I guess if we expect a lot of compilers to be making language-specific derivations or replacements of the ast-ost stage then putting the ost specifications into HLLCompiler makes some sense, but I totally agree with chromatic that a more generic approach is needed here. And what I had been aiming for in terms of array of compiler tasks was something like array of compiler stages, where each compiler stage is itself a compiler (in the compreg and HLL compiler sense) that does the transformation to the next item in the list. And each compiler stage knows the details of how it performs its transformation, whether that's using TGE or some other method. I completely agree on the idea of giving each stage its own compiler, and making that compiler aware of everything it needs to know to perform its own stage of compilation. I also completely agree on putting as little code as possible for performing the compilation into the HLLCompiler module. Where we diverge is that I don't want the compiler for one stage to know anything about the next stage. Each stage should operate independently, and only the HLLCompiler should control the order of stages. Part of me really wishes that each compiler task would end up being a standardized 'apply' or 'compile' subroutine or method of each stage. In other words, to have compilation effectively become a sequence like: .local pmc code # source to parse tree $P0 = get_hll_global ['Perl6::Grammar'], 'apply' code = $P0(code, adverbs :flat :named) # parse tree to ast $P0 = get_hll_global ['Perl6::PAST::Grammar'], 'apply' code = $P0(code, adverbs :flat :named) # ast to ost $P0 = get_hll_global ['POST::Grammar'], 'apply' code = $P0(code, adverbs :flat :named) # ost to result $P0 = get_hll_global ['POST::Compiler'], 'apply' code = $P0(code, adverbs :flat :named) Here the 'apply' functions in Perl6::PAST::Grammar and POST::Grammar are simply imported from TGE and do the steps of creating the builder object and then applying the grammar. The 'apply' function in Perl6::Grammar would just be a standardized start rule for the parser grammar (and can be directly specified as such in the .pg file). If we could standardize at this level, then a compiler simply specifies the sequence of things to be applied, and the above instructions could be implemented with a simple iterator over the sequence. This is _really_ what I was attempting to get at by having separate compiler objects for PAST, POST, and friends, except that instead of calling the standard function 'apply' I was using 'compile'. Hm actually, I like this a lot better than registering a compiler for POST and retrieving it by 'compreg'. I would push it one step farther, though. Instead of setting 'astgrammar' in HLLCompiler's 'init' method, set 'astcompiler'. The revised method for a stage (using the parse-tree-to-AST as an example) would be as follows, where the method only performs error checks to make sure that it got a valid class name, creates a compiler object for that stage, and calls 'compile'. (Here I'm using the naming scheme from below.) .sub 'compile_parse_tree' :method .param pmc source .param pmc adverbs :slurpy :named .local string ptcompiler_name .local pmc ptcompiler ptcompiler_name = self.'ptcompiler'() unless ptcompiler_name goto err_no_ptcompiler $I0 = find_type ptgrammar_name ptcompiler = new $I0 .return ptcompiler.'compile'(source) err_no_ptcompiler: $P0 = new .Exception $P0['_message'] = 'Missing ptcompiler in compiler' throw $P0 .end For now, we create a separate compiler object for each tree grammar, but ultimately TGE could generate the appropriate 'compile' method in each generated tree grammar class. Part of me thinks that 'apply' and 'compile' are pretty much the same thing, in the sense that both refer to using some sort of transformer thing to
Re: Re: Re: [perl #41014] [PATCH] Autobox Native Types for MultiSubs
Patrick R. Michaud [EMAIL PROTECTED] wrote: On Wed, Nov 29, 2006 at 04:43:59PM -0500, Matt Diephouse wrote: Leopold Toetsch [EMAIL PROTECTED] wrote: Am Mittwoch, 29. November 2006 05:50 schrieb Matt Diephouse: It also means that string, int, and float no longer work as MMD types -- you can't distinguish between native types and PMCs. I think this is the right way to go now that we have autoboxing; I don't see any reason to differentiate. I don't think this is the best strategy. It seriously prevents all native type optimizations. While 'Integer' should be MMD-distancewise close to 'int', it should not be the same. What native type optimizations? Using S, I, and N registers? If using an I register is faster, wouldn't you want to unbox an Integer PMC and use an I register anyway? Sure, but Parrot is unboxing for us already, without us having to do anything special: .sub 'foo' :multi(_, String) .param int abc .param pmc xyz ... .end foo(1, 'xyz') # boxes 'xyz', leaves 1 alone foo($P0, $P1) # unboxes $P0 to an int, leaves $P1 alone That's the point I was trying to make. I can't think of any case where you would want to have a different param type based on whether you passed a native type: .sub 'foo' :multi(int) .param int abc ... .end .sub 'foo' :multi (Integer) .param pmc abc ... .end Because what would be the point? If using a native type in the sub is faster, then use it no matter what: unbox the PMC. If it's not faster, then there's no optimization and you may as well autobox to a PMC when a native type is passed in. I'm not at all an expert on the topic of multis, but it sounds to me as though :multi is being somehow conflated with when to auto[un]?box. I think :multi should limit itself to being a way of selecting which sub(s) to call, while autoboxing should be based solely on the arguments of the caller and parameters of the called sub (once that sub has been chosen by :multi). Even with the patch, :multi limits itself to being a way of selecting which sub(s) to call, so no worries there. It's not that I have my heart set against dispatching on native types, but I would like to see a reason for it. Leo mentioned optimization, but I don't see how that applies. We've basically run into the fact that there's no spec for MMD. I'll see if I can provide a patch that just makes _ match native types, but I think it'll be somewhat more involved than this one. -- Matt Diephouse http://matt.diephouse.com
Re: [svn:perl6-synopsis] r13487 - doc/trunk/design/syn
[EMAIL PROTECTED] writes:
Log:
More entries in smartmatch table.
+++ doc/trunk/design/syn/S03.pod Wed Nov 29 09:20:50 2006
+HashHash hash keys identical match if $_.keys === $x.keys
+HashSet members identicalmatch if $_.keys === $x
+Set Set members identicalmatch if $_ === $x
+Hashany(Hash) hash key intersectionmatch if exists
$_{any(Hash.keys)}
Should that last one have a C$x in the code somewhere?
Smylers
Re: beg for Bag
TSa wrote: Jonathan Lang wrote: Note that this would mean that Seq would also have set operations. I count this as an advantage. So one can write (1,2,3) (|) (2,2,3,4,4) to get a result of (1,2,2,3,4,4). As long as the Seq is a Set, that is it has no duplicates, you get Set behavior through the Bag ops: (1,2,3) (|) (2,3,4) === (1,2,3,4); (1,2,3) () (2,3,4) === (2,3). Would (1,2,2,3,4,4) be a Seq or a Bag? IMHO, the _only_ way this could work would be if it's a Bag: if it's a Seq, I see no way that one could resolve '(1,2,3) ∪ (3,1,2)'. Mind you, I'm still not sold on the idea of performing set operations on Seqs - it may be technically feasible to do so, but it strikes me as fundamentally unintuitive. BTW, the set/bag operations are not yet mentioned in S03 as new operators. Here's a list what I think they should be: (|) union () intersection (^) symmetric difference (/) disjoint union? (!) complement, this is difficult because you need the surrounding set (-) difference (+) join, returns a bag (*) cartesian product (**) powerset (in) membership (!in) negated membership () proper subset () proper superset (=) subset (=) superset (=) equality, also with === (!=) inequality, also with !=== Initial thought: overkill. Several of these operations (e.g., the Cartesian product) are obscure and only of interest to mathematicians. This isn't a reason to exclude them; but a non-mathematician should not be made to feel like he needs to get a math degree in order to use sets. (On a tangent, he also shouldn't be made to feel like he has to learn Type Theory in order to use Perl6's type system.) I'm still bothered by the idea that you have to wrap _every_ ASCII representative of a set operation in parentheses - something which is only necessary when you start applying the full range of set operations to non-Set entities. In particular, I want 'Set - Set' to produce the difference of the two Sets. Setting aside the issue of the notation to be used, there are several concerns that I have with this: If set operations also apply to Seq, then (=) is not the same as ===. The former ignores the order of the terms; the latter only does so for Sets and Bags. In a way, this is what started the whole debate. You mention a single disjoint union operator: is it supposed to be the disjoint union comparison operator (i.e., it returns true if the sets are disjoint), or the disjoint union composition operator (which returns a Set of Pairs, with each element being keyed according to the Set that it was originally in)? Saying that complement is difficult is an understatement. I suppose you _could_ get it to work by having a 'complemented Set' would keep track of which elements it _doesn't_ have; but this opens a can of worms that I really don't think we want to get into (e.g., A ∪ (!)B). And the notion of a complement with regard to the surrounding set is already handled by the difference operator. A Cartesian product would return a Set (or Bag, depending on the left term) of Pairs, keyed by the elements of the left term. A powerset strikes me as something that you'd want to do as a 0-ary method, rather than as an operator. Did I forget something? You did highlight some things - for instance, a Set of Pairs is _not_ a Hash: a Hash has a further requirement that every key must be unique, whereas a Set of Pairs allows for duplicate keys (but not duplicate key-value pairs; go with a Bag of Pairs for that). -- Jonathan Dataweaver Lang
Re: Re: Re: Re: [perl #41014] [PATCH] Autobox Native Types for MultiSubs
Matt Diephouse [EMAIL PROTECTED] wrote: We've basically run into the fact that there's no spec for MMD. I'll see if I can provide a patch that just makes _ match native types, but I think it'll be somewhat more involved than this one. It ended up being easier than expected -- implemented in r15910. -- Matt Diephouse http://matt.diephouse.com
