Re: Associative class for any key, any value

[yary]

Yep that's it, thanks!

> my Any %h{ Any };

> %h{ 22 } = "foo"; %h{ "22" } = IO; %h{ IO } = sub { ... };

> %h.kv.raku;

(IO, sub { ... }, 22, "foo", "22", IO).Seq
-y


On Wed, Aug 26, 2020 at 8:04 PM Brad Gilbert  wrote:

>
> On Wed, Aug 26, 2020 at 9:56 PM yary  wrote:
>
>> Map and its descendants like Hash relate "from *string* keys to values
>> of *arbitrary* types"
>> QuantHash and its descendants like Mix, Bag, Set "provide *object*
>> hashes whose values are *limited* in some way"
>>
>> Is there an associative class where both the keys and values are
>> arbitrary?
>>
>
> Hash[Any,Any]
>
> my Any %h{ Any }
>

Re: Associative class for any key, any value

[Brad Gilbert]

On Wed, Aug 26, 2020 at 9:56 PM yary  wrote:

> Map and its descendants like Hash relate "from *string* keys to values of
> *arbitrary* types"
> QuantHash and its descendants like Mix, Bag, Set "provide *object* hashes
> whose values are *limited* in some way"
>
> Is there an associative class where both the keys and values are arbitrary?
>

Hash[Any,Any]

my Any %h{ Any }

Associative class for any key, any value

[yary]

Map and its descendants like Hash relate "from *string* keys to values of
*arbitrary* types"
QuantHash and its descendants like Mix, Bag, Set "provide *object* hashes
whose values are *limited* in some way"

Is there an associative class where both the keys and values are arbitrary?

-y

Re: Seq whitespace sensitivity? (was Re: print particular lines question)

[Tobias Boege]

On Wed, 26 Aug 2020, Tobias Boege wrote:
> Observe:
> 
>   > 1 ...^ 20
>   (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)
> 
>   > 1 ... ^20  # actually C«1 ... (0..19)»
>   (1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)
> 
> The documentation [1] states that the C«...» infix is list-associative
> and while I have never seen an example of that (including in that docs
> page), it would explain why it happily takes in your list (1) and then
> your list (0 .. 19) and concatenates them into a sequence, without
> applying any of the usual sequence operator magic.

And I must correct myself. The associativity has nothing to do with this.
I don't know where my mind was when I wrote that. From the documtation,
I would blame the slurpy argument **@ for that behavior of just taking in
lists and effectively iterating them into a new Seq, and in Rakudo it is
apparently this special candidate:

  # https://github.com/rakudo/rakudo/blob/e2855aa/src/core.c/operators.pm6#L129
  multi sub infix:<...>(\a, Mu \b) {
  Seq.new(SEQUENCE(a, b))
  }

Best,
Tobias

Re: Extended identifiers in named attributes

[Brad Gilbert]

The problem is that often adverbs are chained without a comma.

my %h = (a => 1);

%h{'a'}:exists:delete # True
say %h.keys; # ()

---

my %h = (a => 1);

postcircumfix:< { } >( %h{'a'}, :exists:delete ) # True
say %h.keys; # ()

On Wed, Aug 26, 2020 at 7:31 AM Marcel Timmerman  wrote:

> Hi everyone,
>
> I was experimenting with extended identifiers and found that it is not
> possible to use it in named attributes. E.g.
>
> > sub a (:$x:y) { say $x:y; }
> ===SORRY!=== Error while compiling:
> Unsupported use of y///.  In Raku please use: tr///.
> --> sub a (:$x:y⏏) { say $x:y; }
>
>
> > sub a (:$abc:def) { say $abc:def; }
> ===SORRY!=== Error while compiling:
> Invalid typename 'def' in parameter declaration.
> --> sub a (:$abc:def⏏) { say $abc:def; }
>
>
> Is there a trick of some sort to get this done? At the moment I can only
> use a slurpy hash and check for its keys. This is good enough for me but
> out of curiosity I ask. If not possible, an extra note in the documentation
> on named arguments would be necessary.
>
> regards,
> Marcel
>
>
>

Re: Seq whitespace sensitivity? (was Re: print particular lines question)

[William Michels via perl6-users]

On Wed, Aug 26, 2020 at 10:33 AM Tobias Boege  wrote:
>
> On Wed, 26 Aug 2020, William Michels via perl6-users wrote:
> > > They can be pretty great, especially when combined with the magic op= 
> > > operators that (in essence) know about identity elements.  I've done a 
> > > few challenges on the Code Golf Stackexchange site where I wanted an 
> > > infinite sequence like this:
> > >
> > > 0, 1, -2, 3, -4, 5, -6, ...
> > >
> > > It took me a while to realize this can be expressed in Raku simply as:
> > >
> > > { $++ * ($ *= -1) } ... *
> > >
> >
> > Hi Sean, that's a neat solution! I seem to have found an oddity though
> > (whitespace sensitivity). In the REPL:
> >
> > > say { $++ * ($ *= -1) } ...21
> > (0 1 -2 3 -4 5 -6 7 -8 9 -10 11 -12 13 -14 15 -16 17 -18 19 -20 21)
> > > say { $++ * ($ *= -1) } ...^21
> > (0 1 -2 3 -4 5 -6 7 -8 9 -10 11 -12 13 -14 15 -16 17 -18 19 -20)
> > > say { $++ * ($ *= -1) } ... 21
> > (0 1 -2 3 -4 5 -6 7 -8 9 -10 11 -12 13 -14 15 -16 17 -18 19 -20 21)
> > > say { $++ * ($ *= -1) } ... ^21
> > (0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20)
> >
> > I would have expected the last line of code (whitespace between "..."
> > and "^21") to give the same answer as the first three. Any ideas?
> >
>
> The difference is likely to come from the fact that "^20" as a term is
> a shorthand for the range "0..^20", while "...^" is the sequence operator
> with exclusive endpoint. Placement of whitespace will dictate where the
> little hat attaches to and thus change the meaning of the statement.
>
> Observe:
>
>   > 1 ...^ 20
>   (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)
>
>   > 1 ... ^20  # actually C«1 ... (0..19)»
>   (1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)
>
> The documentation [1] states that the C«...» infix is list-associative
> and while I have never seen an example of that (including in that docs
> page), it would explain why it happily takes in your list (1) and then
> your list (0 .. 19) and concatenates them into a sequence, without
> applying any of the usual sequence operator magic.
>
> When you write "1 ...^20" I suppose that longest-token matching prefers
> the former interpretation as it makes the infix token longer.
>
> Best,
> Tobias
>
> [1] https://docs.raku.org/language/operators#index-entry-..._operators
>
> --
> "There's an old saying: Don't change anything... ever!" -- Mr. Monk


Thank you, Tobias! Here's my take (REPL, below):

> 1...20
(1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20)

> 1... 20
(1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20)

> 1...^20
(1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)

> 1... ^20
(1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)

WOW. I never would have expected the last line of code above to return
a sequence starting "1, 0, 1 ..." up to 19.

Would I ever want that sequence? Couldn't I get that sequence just as
easily by asking for a sequence of (-1 ... ^20), and then calling
abs() on each element (using hyper)? See below:

> (-1... ^20)>>.abs
(1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)
>

Anyway, I opened a Github issue, and (like yourself here), Jonathan
has graciously replied. Feel free to chime in at:

https://github.com/rakudo/rakudo/issues/3881

Thanks again, Bill.

Re: Extended identifiers in named attributes

[Marcel Timmerman]

On 2020-08-26 17:48, Tom Browder wrote:
On Wed, Aug 26, 2020 at 07:31 Marcel Timmerman > wrote:


I was experimenting with extended identifiers and found that it is

not possible to use it in named attributes. E.g.

> sub a (:$x:y) { say $x:y; }

Are you sure that is supposed to work without some kind of () or <> 
like a module identifier? But a doc note would be helpful.


Best regards,

-Tom

Hi Tom,

One example from the doc is: WOW:That'sAwesome, so yes, I believe that 
should be possible. Also I've already used this in Xml::Actions where 
function names can be named like abc:def:start(). A small REPL test 
shows also that a simple assignment works on these type of variables;



my $abc:def = 10;

10

say $abc:def;

10

Regards,
Marcel

Re: Seq whitespace sensitivity? (was Re: print particular lines question)

[Tobias Boege]

On Wed, 26 Aug 2020, William Michels via perl6-users wrote:
> > They can be pretty great, especially when combined with the magic op= 
> > operators that (in essence) know about identity elements.  I've done a few 
> > challenges on the Code Golf Stackexchange site where I wanted an infinite 
> > sequence like this:
> >
> > 0, 1, -2, 3, -4, 5, -6, ...
> >
> > It took me a while to realize this can be expressed in Raku simply as:
> >
> > { $++ * ($ *= -1) } ... *
> >
> 
> Hi Sean, that's a neat solution! I seem to have found an oddity though
> (whitespace sensitivity). In the REPL:
> 
> > say { $++ * ($ *= -1) } ...21
> (0 1 -2 3 -4 5 -6 7 -8 9 -10 11 -12 13 -14 15 -16 17 -18 19 -20 21)
> > say { $++ * ($ *= -1) } ...^21
> (0 1 -2 3 -4 5 -6 7 -8 9 -10 11 -12 13 -14 15 -16 17 -18 19 -20)
> > say { $++ * ($ *= -1) } ... 21
> (0 1 -2 3 -4 5 -6 7 -8 9 -10 11 -12 13 -14 15 -16 17 -18 19 -20 21)
> > say { $++ * ($ *= -1) } ... ^21
> (0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20)
> 
> I would have expected the last line of code (whitespace between "..."
> and "^21") to give the same answer as the first three. Any ideas?
> 

The difference is likely to come from the fact that "^20" as a term is
a shorthand for the range "0..^20", while "...^" is the sequence operator
with exclusive endpoint. Placement of whitespace will dictate where the
little hat attaches to and thus change the meaning of the statement.

Observe:

  > 1 ...^ 20
  (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)

  > 1 ... ^20  # actually C«1 ... (0..19)»
  (1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19)

The documentation [1] states that the C«...» infix is list-associative
and while I have never seen an example of that (including in that docs
page), it would explain why it happily takes in your list (1) and then
your list (0 .. 19) and concatenates them into a sequence, without
applying any of the usual sequence operator magic.

When you write "1 ...^20" I suppose that longest-token matching prefers
the former interpretation as it makes the infix token longer.

Best,
Tobias

[1] https://docs.raku.org/language/operators#index-entry-..._operators

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk

Seq whitespace sensitivity? (was Re: print particular lines question)

[William Michels via perl6-users]

> They can be pretty great, especially when combined with the magic op= 
> operators that (in essence) know about identity elements.  I've done a few 
> challenges on the Code Golf Stackexchange site where I wanted an infinite 
> sequence like this:
>
> 0, 1, -2, 3, -4, 5, -6, ...
>
> It took me a while to realize this can be expressed in Raku simply as:
>
> { $++ * ($ *= -1) } ... *
>

Hi Sean, that's a neat solution! I seem to have found an oddity though
(whitespace sensitivity). In the REPL:

> say { $++ * ($ *= -1) } ...21
(0 1 -2 3 -4 5 -6 7 -8 9 -10 11 -12 13 -14 15 -16 17 -18 19 -20 21)
> say { $++ * ($ *= -1) } ...^21
(0 1 -2 3 -4 5 -6 7 -8 9 -10 11 -12 13 -14 15 -16 17 -18 19 -20)
> say { $++ * ($ *= -1) } ... 21
(0 1 -2 3 -4 5 -6 7 -8 9 -10 11 -12 13 -14 15 -16 17 -18 19 -20 21)
> say { $++ * ($ *= -1) } ... ^21
(0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20)

I would have expected the last line of code (whitespace between "..."
and "^21") to give the same answer as the first three. Any ideas?

Best, Bill.

Re: Extended identifiers in named attributes

[Tom Browder]

On Wed, Aug 26, 2020 at 07:31 Marcel Timmerman  wrote:

I was experimenting with extended identifiers and found that it is
>
> not possible to use it in named attributes. E.g.
>
> > sub a (:$x:y) { say $x:y; }
>
> Are you sure that is supposed to work without some kind of () or <> like a
module identifier? But a doc note would be helpful.

Best regards,

-Tom

Re: Extended identifiers in named attributes

[Gianni Ceccarelli]

On Wed, 26 Aug 2020 14:31:06 +0200
Marcel Timmerman  wrote:

> I was experimenting with extended identifiers and found that it is
> not possible to use it in named attributes. E.g.
> 
> > sub a (:$x:y) { say $x:y; }
> ===SORRY!=== Error while compiling:
> Unsupported use of y///.  In Raku please use: tr///.
> --> sub a (:$x:y⏏) { say $x:y; }
> 
> > sub a (:$abc:def) { say $abc:def; }
> ===SORRY!=== Error while compiling:
> Invalid typename 'def' in parameter declaration.
> --> sub a (:$abc:def⏏) { say $abc:def; }

Also::

  > sub a( :foo($a:x) ) { say $a:x; }
  ===SORRY!=== Error while compiling:
  Unable to parse named parameter; couldn't find right parenthesis
  --> sub a( :foo($a⏏:x) ) { say $a:x; }

feels like a parse problem to me. I'd say submit a bug report.

-- 
Dakkar - 
GPG public key fingerprint = A071 E618 DD2C 5901 9574
 6FE2 40EA 9883 7519 3F88
key id = 0x75193F88

Re: Extended identifiers in named attributes

[William Michels via perl6-users]

Hi Marcel, It almost looks to me that a pair of characters--possibly
the two colons--is being interpreted as an alternative delimiter for
the tr/// operator. I'd suggest this is a bug, so you should consider
opening an issue on Github. But I have little experience with "named
attributes", so does anyone else care to chime in?

Best, Bill.


On Wed, Aug 26, 2020 at 5:31 AM Marcel Timmerman  wrote:
>
> Hi everyone,
>
> I was experimenting with extended identifiers and found that it is not 
> possible to use it in named attributes. E.g.
>
> > sub a (:$x:y) { say $x:y; }
> ===SORRY!=== Error while compiling:
> Unsupported use of y///.  In Raku please use: tr///.
> --> sub a (:$x:y) { say $x:y; }
>
>
> > sub a (:$abc:def) { say $abc:def; }
> ===SORRY!=== Error while compiling:
> Invalid typename 'def' in parameter declaration.
> --> sub a (:$abc:def) { say $abc:def; }
>
> Is there a trick of some sort to get this done? At the moment I can only use 
> a slurpy hash and check for its keys. This is good enough for me but out of 
> curiosity I ask. If not possible, an extra note in the documentation on named 
> arguments would be necessary.
>
> regards,
> Marcel
>
>

Extended identifiers in named attributes

[Marcel Timmerman]

Hi everyone,

I was experimenting with extended identifiers and found that it is not 
possible to use it in named attributes. E.g.



sub a (:$x:y) { say $x:y; }

===SORRY!=== Error while compiling:
Unsupported use of y///.  In Raku please use: tr///.
--> sub a (:$x:y⏏) { say $x:y; }



sub a (:$abc:def) { say $abc:def; }

===SORRY!=== Error while compiling:
Invalid typename 'def' in parameter declaration.
--> sub a (:$abc:def⏏) { say $abc:def; }

Is there a trick of some sort to get this done? At the moment I can only 
use a slurpy hash and check for its keys. This is good enough for me but 
out of curiosity I ask. If not possible, an extra note in the 
documentation on named arguments would be necessary.


regards,
Marcel

Re: Readline package

[p.spek via perl6-users]

On Fri, Aug 21, 2020 at 11:43:34AM -0500, Daniel ”Fooist” Lathrop wrote:
> Hi Patrick,
> 
> What do you think? 
> 
> -Daniel
> 
> Sent from my iPhone
> 
> Daniel Lathrop (@lathropd)
> Mobile: (206) 718-0349 
> PGP key: https://keybase.io/lathropd (raw) 

Hi Daniel,

I've just started on making the new Rakudo Star (2020.08.1), and I've also
noticed some slight readline issues.

While I respect Jeff's work, time does pass, and things break. I think the most
respect we can show is to continue the work he started.

With regards to updating it, in Raku we have a :auth<> tag on the modules, or
just the auth key in the META6.json. You can alter this to whatever (it just
needs to be a string, though personally I think this ought to have some
standards), and you can upload a module with the same name to CPAN afterwards.
By default, zef selects the highest version, but people can opt to use another
author's variant by specifying an :auth<> themselves.

As for Rakudo Star inclusion, I pull all the modules directly from git, or
download tarballs over HTTP. All I need is a URL to fetch the correct version
from. If you could give me this, I will update the readline package used in
Rakudo Star for the next release.

-- 
With kind regards,

Patrick Spek


www:  https://www.tyil.nl/
mail: p.s...@tyil.nl
pgp:  1660 F6A2 DFA7 5347 322A  4DC0 7A6A C285 E2D9 8827

social: https://soc.fglt.nl/tyil
git:https://home.tyil.nl/git


signature.asc
Description: PGP signature