Found nothing!
Created
July 19, 2019 20:23
-
-
Save Whateverable/649fd2ad0865dec41d3e106719815678 to your computer and use it in GitHub Desktop.
quotable6
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| QuantHash |
ah, yes, the coercer uses Pair semantics for all QuantHashes
�R#1658 [open]�: https://github.com/rakudo/rakudo/issues/1658 �[@LARRY][NYI][testneeded] Why do Array / Hash not have .grab like QuantHashes do?�
�R#1658 [open]�: https://github.com/rakudo/rakudo/issues/1658 �[@LARRY][NYI] Why do Array / Hash not have .grab like QuantHashes do?�
�R#1658 [open]�: https://github.com/rakudo/rakudo/issues/1658 �[@LARRY][NYI][testneeded] Why do Array / Hash not have .grab like QuantHashes do?�
rakudo-moar dd2c90192: OUTPUT: «Invocant of method 'SET-SELF' must be an object instance of type 'QuantHash', not a type object of type 'SetHash'. Did you forget a '.new'? in block at <tmp> line 1 in block <unit> at <tmp> line 1»
signs == &list and .list are not equivalent. There's no equivalence with, say, QuantHashes. Same as there's no equivalency between &hash and .hash
&list(Seq:D) giving a 1-item list with that Seq in it; (c) I don't want to leave special Seq:D -> List handling in &list, since we don't do anything special for containerazied Positionals or QuantHashes
well, if that would be an issue. we would have seen it earlier with QuantHashes, as they use the same mechanism
¦ rakudo: - by implementing .STORE for all QuantHash types
¦ rakudo/nom: - remove some Any,QuantHash / QuantHash,Any candidates
¦ rakudo/nom: 975fcf6cfd | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
affecting all QuantHashes and object hashes
¦ rakudo/nom: a91ad2da85 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
Does anybody see any problem with object hashes inheriting from QuantHash, rather than from Map?
fwiw, object hashes are much more like QuantHashes internally, because the keys are always .WHICH strings
lizmat: Is this sufficiently complete to capture the current Associative type graph, or is there more this isn't showing? https://docs.perl6.org/type/QuantHash
¦ rakudo/nom: 710fa80004 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: QuantHashes.
¦ rakudo/nom: 923c32e688 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: 8e960522e5 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ roast: - add tests for the union of 3 empty QuantHashes
¦ roast: - add tests for the symmetric difference of 3 empty QuantHashes
¦ rakudo/nom: 3f6bffdbce | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: 0cf3487160 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: �Make QuantHash.new(Nil) and Nil.QuantHash consistent�
¦ rakudo/nom: than generating a QuantHash.new(Any).
¦ rakudo/nom: 5074158712 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ roast: QuantHash type.
¦ roast: QuantHash type.
¦ rakudo/nom: 2eeb000c94 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: a526d839f5 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: 45aef27497 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: - allows for any mix of QuantHash, Iterable, Mappy or Any types
¦ rakudo/nom: �Fix a few edge cases of (^) wrt QuantHash type permutations�
¦ rakudo/nom: �Hide QuantHash.raw_keys as R:Q.RAW-KEYS�
¦ rakudo/nom: �Obscurize QuantHash.raw_hash to QuantHash.RAW-HASH�
¦ rakudo/nom: 73c3bcc662 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: �Introducing Rakudo::QuantHash::Quanty role�
¦ rakudo/nom: The QuantHash equivalent of Rakudo::Iterator::Mappy
¦ rakudo/nom: This reduces the usage of QuantHash.hll_hash, but not eliminates it
¦ rakudo/nom: 125bc437df | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: Removes one more usage of QuantHash.hll_hash
¦ rakudo/nom: �Make sure unhandled failures don't coerce QuantHashy�
¦ rakudo/nom: �We probably want to QuantHash handled Failures�
¦ rakudo/nom: 5e34258850 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: f34af72fc7 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: d5bf5b0c25 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
Should QuantHash be Iterable? Maps are. But on the other hand the fact that slurpies break Maps into Pairs is kidna meh, so would we want the same to happen with QuantHashes?
I think current way is fine. But I might write an article about Perl 6 Iterables and so wanted to find out if QuantHash isn't one on purpose :)
DeadDelta: could you check if something breaks if you add "does Iterable" to the QuantHash role ?
Yeah, it already got its own iterator. So I think what will be affected is how QuantHashes flatten in slurpies or .deepmap or .nodemap or ».foo
¦ rakudo/nom: ce20887760 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: d765f1864e | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: b59aad15cb | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: c727462cde | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: d183846116 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: 5fb6d67921 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: 1f5bed4b4b | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: �Tighten up all inter-QuantHash coercions/clone�
¦ rakudo/nom: f3b2d952d6 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: 9d14a72486 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: 3267386b70 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ roast: �Add tests for QuantHash.new() not accepting laziness�
¦ rakudo/nom: bf95bcb6c0 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: 86c3d7aa1f | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: fb9e1a87fe | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ roast: �Add .QuantHash/QuentHash.new-from-pairs lazy tests�
¦ rakudo/nom: 7fa8568254 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: 0104a439f3 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: existence of Rakudo::QuantHash and should have been created in there.
¦ rakudo/nom: 7f84df1db3 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: 1369632fb1 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: actually use this logic for QuantHash (<=) Set and Set (<=) QuantHash
¦ rakudo/nom: So we don't need to coerce QuantHash to Set anymore for (<=) and
¦ rakudo/nom: 539415cf7d | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: c9c1ee3dcc | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: �Streamline QuantHash.(hash|Hash)�
¦ rakudo/nom: - .Hash returns an object hash with value limited to QuantHash meaning
¦ rakudo/nom: 4b1b349424 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: abc0509c5c | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: 5528b10644 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: �Handle QuantHash:U coercion differently�
¦ rakudo/nom: instead of not coercing a QuantHash type object, we now coerce it into
¦ rakudo/nom: a defined QuantHash object with the type object as its member.
¦ rakudo/nom: c1e681958e | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: 08b5c1019f | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: 20cfd6b7c6 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: e2c3499b6c | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: 83e82c6d55 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: 75ecaf530f | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: 037070d8b5 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: 1f80dba186 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: �Move QuantHash helper methods to Rakudo::QuantHash�
¦ rakudo/nom: �Move R:I:WeightedRole to R:QuantHash�
¦ rakudo/nom: d672424efc | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: 7404c706ff | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm
¦ rakudo/nom: 5e74017d60 | (Zoffix Znet)++ | src/core/QuantHash.pm
¦ rakudo/nom: �Implement QuantHash.Capture�
¦ rakudo/nom: So users could unpack all the QuantHashes into stuff
¦ roast: �Test QuantHash.Capture�
¦ rakudo/nom: - somehow was missed in the other QuantHash coercion improvements
¦ rakudo/nom: 0abf144476 | (Elizabeth Mattijsen)++ | src/core/QuantHash.pm
¦ rakudo/nom: �Add QuantHash.raw_keys�
¦ rakudo/nom: Returns a list_s of the keys of a QuantHash. Handy for things like
¦ rakudo/nom: �Make QuantHash.raw_hash return "inner" nqp::hash�
¦ rakudo/nom: extra nqp::getattr. Small step towards making %!elems in QuantHash
¦ rakudo/nom: �Using IterationSet for QuantHashes�
¦ rakudo/nom: This commit uses the new IterationSet for QuantHash creation.
¦ rakudo/nom: creation for each new QuantHash, thereby reducing memory pressure.
¦ rakudo/nom: �Make (cont)/(elem) 25% to 5x faster for QuantHashes�
rakudo/nom: �Give Baggy an iterator, move .pairs to QuantHash�
m: say Hash ~~ Iterable; say QuantHash ~~ Iterable # shouldn't these be both True ?
lizmat: Hash is Map, which does both Iterable and Associative. QuantHash on the other hand does Associative directly.
lizmat: without looking deeply into it, my guess is that QuantHash ought to is Map, just like Hash.
well, that's the thing: QuantHash is a role, just like Associative
lizmat: I see Setty does QuantHash
Is this crappy? multi method AT-KEY(QuantHash:U \SELF: $key) is raw { SELF = self.new; SELF.AT-KEY($key); }
rakudo/nom: 79bb867 | (Zoffix Znet)++ | src/core/QuantHash.pm:
rakudo/nom: Make QuantHash:U AT-KEY autovivify to QuantHash object, not Hash
rakudo/nom: Fix by adding AT-KEY for QuantHash:U; a role that Setties and Baggies do
rakudo/nom: b1f77c8 | lizmat++ | src/core/QuantHash.pm:
roast: Adjust exceptions thrown by autovivification of immutable QuantHashes
roast: of QuantHashes[^1]. However, that work did not handle immutable QuantHashes
rakudo-moar 435f7e: OUTPUT: «((Setty) (QuantHash) (Associative))?»
m: say BagHash ~~ QuantHash # timotimo
.oO(maybe it should be called QuantHashy)Oo
nadim_: QuantHash is the generic term for Set,SetHash,Bag,BagHash,Mix,MixHash
Bag's end up being coerced to a Set, which slows things down. could that be broadened to QuantHash?
Seq don't do Positional, only Iterable is shared between Seq and Lists. But note that Maps do it as well and I recall a convo on how about making QuantHash do it too
and does Baggy, and QuantHash
m: say QuantHash.^roles
it came from QuantHash
Or I guess one. the AT-KEY on QuantHash: https://github.com/rakudo/rakudo/commit/c13e67b3e9db3652c75fa1423ba35821c9aac0e8
Unavowed: a Set is considered to be a QuantHash of Bool
rakudo-moar 3fda0b: OUTPUT«((Baggy) (QuantHash) (Associative))»
rakudo-moar 3fda0b: OUTPUT«Baggy MuQuantHash MuAssociative Mu»
class QuantHash does Associative { } should this be role QuantHash does Associative { }
doc: Iterable and QuantHash are roles
moritz: I asket because I saw your name in https://design.perl6.org/S32/Containers.html#QuantHash :)
but then QuantHash has a method maxpairs...
I guess if we moved out minpairs/maxpairs out of the QuantHash role, into Any-iterable, it would just work
rakudo/nom: b70ba13 | (Stefan Seifert)++ | src/core/QuantHash.pm:
rakudo/nom: Have QuantHash's and decsendants' .list return a List instead of Seq
TimToady: That whole "hashy" part of the type hierarchy (EnumMap, Hash, PairMap, QuantHash & co) is kind of a mess.
well, as I'm more familiar with QuantHash and anything below it, I agree it's a mess
rakudo/nom: 52b6f29 | lizmat++ | src/core/QuantHash.pm:
lizmat: so i started digging back into my set op stuffs recently. i had a plan to implement a Setty symmetric difference and a QuantHash one
wait, a second, that would only be a problem for a multi, not for a QuantHash specific symdif op
rakudo/nom: Get Mixes working properly with the QuantHash ops
in order to be a bit more DRY, i'd like to create a helper function for converting to the correct QuantHash type set_operators.pm
In Rakudo: role Mixy does Baggy, and role Baggy does QuantHash
In S32/Containers: «role QuantHash[::T, $default = Any] does Mixy does Associative {...}»
smls: the spec says use QuantHash
doesn't seem to be recursive (^^did not list QuantHash and Associative)
anything non-QuantHash gets wrapped
(or maybe QuantHash)
nope, unless role composition is... minpairs/maxpairs live in the QuantHash role
IO::Handle, IO::FileTestable, Mix, MixHash, Mixy, QuantHash, Set, SetHash, Setty, regexes
{Set,Bag,Mix}{,Hash} haven't been updated for the docs. Should the docs have the hypothetical parametric QuantHash-based set-up described in S32, or the less ideal way they're implemented in Rakudo?
r: say QuantHash ~~ Mixy
doc: dcbdcb6 | Mouq++ | lib/QuantHash.pod:
doc: Steal most of S32/Containers QuantHash description
(assuming the QuantHash is just a mystical beast)
And I'm curious as to why only QuantHash has a .grab method, and not any other container
QuantHash is a role
r: say SetHash ~~ QuantHash
r: say Set ~~ QuantHash
anyway, Set shouldn't do QuantHash in my book
so rakudobug on reporting Set ~~ QuantHash as true
TimToady: re http://irclog.perlgeek.de/perl6/2013-12-07#i_7969313 : there is no QuantHash role implemented just yet
trying to make a proper QuantHash role with %!elems private role attribute
my role Setty does QuantHash {
rakudo/nom: Make sure Int/Num/Numeric/Real work on QuantHashes
roast: KeyHash is now called QuantHash
rakudo/nom: Introduce QuantHash
make: *** No rule to make target `src/core/QuantHash.pm', needed by `CORE.setting.pbc'. Stop.
lizmat: did you forget to git add QuantHash.pm?
gets "don't know how to build QuantHash"... :(
rakudo/nom: 454984b | (Elizabeth Mattijsen)++ | src/core/QuantHash.pm:
rakudo/nom: Oops, forgot to add QuantHash, moritz++
not ok 40 - The object is-a 'QuantHash'
# Actual type: QuantHash
Is QuantHash a role or a class?
ok ... ~~ QuantHash is probably the easy fix
roast: fix QuantHash test
lizmat: it'll probably be a .total method instead of .elems, and we'll probably add an immutable QuantMap to go with QuantHash
I want to make QuantHash the basic role for Set/Bag/Mix as per spec
but then Bag, which does Baggy, which does QuantHash, don't see the attribute anymore :-(
instead keeps QuantHash as a shell role, until the situation improves
I thought we've have QuantHash for the mutable *Hash types, and QuantMap for the Setty,Baggy,Mixy types
specs: distinguish QuantHash role from MixHash instance
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment