On Thu, 11 Jan 2018 20:47:48 -0800, comdog wrote:
> I was playing with higher orders of multiplication and defining some
> operators for them. When I try to make one of my new operators tighter
> than one I've already defined:
>
> multi infix:<↑> ( Int:D $n, Int:D $m --> Int:D )
> is assoc<right>
> is tighter(&infix:<**>)
> { $n ** $m }
>
> multi infix:<↑↑> ( Int:D $, 0 --> Int:D )
> is assoc<right>
> is tighter(&infix:<↑>)
> { 1 }
>
> multi infix:<↑↑> ( Int:D $n, Int:D $m --> Int:D )
> is assoc<right>
> is tighter(&infix:<↑>)
> { [↑] $n xx $m }
>
> put 2 ↑ 3; # 2 * 2 * 2 = 8
> put 2 ↑↑ 3; # 2 ** 2 ** 2 = 16
>
> This gets the odd error about something that's not part of my code:
>
> ===SORRY!=== Error while compiling /Users/brian/Desktop/knuth2.p6.pl
> No such method 'subst' for invocant of type 'Any'
>
> The problem turns out to be my duplication of the tighter. That's
> better left to a proto definition instead of the candidates. I know
> that now but the error message could have helped with that.
>
I fixed the subst crash[^1][^2] and made it warn[^3][^4][^5] when duplicate
traits are used *on the same routine*.
When it came to making it warn for dupe use on more than one routine, I hit
a full can of bugs and giving up on this for now (if anyone wants to pick this
ticket up, go for it).
I drafted[^6] a warning system that tells the user to move traits to the proto
(or to the first multi, for implicit protos) as well as drafted[^7] all traits
changing configuration regardless of which multi they're applied to (doesn't
affect the parsing though but affects the config values themselves globally).
Both ideas are crap and don't quite work out.
Unsure which way to go here.
There's a grammar bug[^8], where we don't change precedence of ops, even if
we completely shadow them. However, if that's fixed, I believe we'll still have
this weird case where a setup like this (O = Op multi candidates; P =
Precedence):
O1-P1; { O2-P2; }
Would have a language that parses `O` with precedence and associativity of `P2`
inside the block, yet both `O1` and `O2` candidates would be available when
calling
that op.
Currently, there's also bug where trying to apply tighter/looser more than once
messes up the configuration (it replaces `=` to `:=`, but if it's already `:=`
it
replaces it to `::=`).
[1]
https://github.com/rakudo/rakudo/commit/029226fe9938e7dcf81144f6b10c0d81ae03450a
[2]
https://github.com/perl6/roast/commit/27f9e2eef6fd9c4caa83ab0315d0a8ce17cd9d62
[3]
https://github.com/rakudo/rakudo/commit/ad60b947e40b91b7755c3a5a7e14e07d1a10c18a
[4]
https://github.com/rakudo/rakudo/commit/732a25c312a73b5daf2e5afbde1ae512988b9e69
[5]
https://github.com/perl6/roast/commit/2dca47b3a1790aedc0832d3381e3b27c3608316c
[6]
https://github.com/rakudo/rakudo/commit/6b17ab1d86e5d2e4984a307062bb21fab2a190d5
[7]
https://github.com/rakudo/rakudo/commit/29a6182698ec9d926a2a7d2b62ecd839b6a22983
[8] https://github.com/rakudo/rakudo/issues/1237
