Re: Rust community in distress

[Daniel Sockwell via perl6-users]

Depending on how many would leave the original product, the pace of 
development of both could be slowed down by a factor of 2 or even more.


That's technically correct (which, after all, is the best kind of 
correct, https://knowyourmeme.com/photos/909991-futurama ).


But while the pace of development *could* be slowed down by a lot, it 
could also be almost entirely unchanged – and, ime, the modal fork gets 
little traction and basically doesn't impact the original project 
(obviously with large exceptions at the tail).  And that's what I expect 
with Rust/Crabby (was that the name of the fork? I just watched the video 
and have already forgotten…)


I have more thoughts re: Rust's issues, but I'll save those for sometime 
when I'm not about to board an airplane.


Jun 9, 2023 4:06:22 PM Vadim Belman :


There is a fork, already. At least, this is what he says in the video.

There is a catch though, and it is mentioned in the video too. A few 
catches, actually. 


First, such conflict-based forks cause harm to project reputation. 

Second, it confuses potential supporters and this could reduce project 
funding. 


Third, developers would get separated between projects. Depending on 
how many would leave the original product, the pace of development of 
both could be slowed down by a factor of 2 or even more.


Best regards,
Vadim Belman

On Jun 9, 2023, at 2:40 AM, İsmail Arılık  
wrote:


This is the open source world! So if there is a problem between the 
management of Rust and the community, a fork would come and be popular 
soon. Leaving Rust shouldn't be an option I think since it is really a 
good language. 


On Fri, Jun 9, 2023, 07:04 Darren Duncan  
wrote:
And here Rust seemed to be massively gaining in popularity, and was 
just
supported officially for Linux kernel driver support etc. -- Darren 
Duncan


On 2023-06-08 11:17 a.m., Parrot Raiser wrote:

See https://youtu.be/QEnuzwCWpgQ 

This is not meant to be an example of schadenfreude.  Rust is an 
interesting
language, whose ecological niche has little in common with Perl's or 
Raku's. Its
principal rival is Go, which is definitely more corporate.   
Alphabet already
controls far too much.  (Yes, that sentiment may not be compatible 
with a gmail

account.)
It is unfortunate when any worthwhile Open Source project suffers 
from community
or personality conflicts. It's worth noting them, to help us avoid 
similar

situations.

Re: Regex surprises

[Daniel Sockwell]

Sean,

To follow up on what Brian said, you can also do the same thing 
on a single line with named captures
https://docs.raku.org/language/regexes#Named_captures

(This often isn't as good as Brian's method, since breaking things
up as Brian showed often helps readability.  But it can be a good 
option if you're trying to keep something concise.)

Using that syntax, your example goes from

S:g[(x)|(y)] = $0 ?? x-replacement !! y-replacement

to

S:g[$=[x]|y] = $ ?? x-replacement !! y-replacement

which is pretty similar.

I hope that helps!

Best,
Daniel 

--
Daniel Sockwell / codesections
Website: www.codesections.com

⏰ Raku conference talk proposals due Sun 18:00 UTC

[Daniel Sockwell via perl6-users]

As a final reminder, the Perl and Raku Conference's call for proposals 
closes in TWO DAYS – on Sunday, May 1 at 18:00 UTC (2pm eastern time).   
Don't forget to submit your talk proposal by then!


(And, if you aren't yet planning to propose a talk, it's not too late to 
do so: you don't need to have the *talk* written by Sunday, just a 
proposal – and that can be as simple as ~250 character blurb about the 
topic.  Regardless of your experience level with Raku, I'd love to hear 
your perspective)


The CFP details: https://www.papercall.io/tprchou22
Conference info: https://tprc.us/tprc-2022-hou/

Re: A natural opportunity for Raku?

[Daniel Sockwell]

February 12, 2022 4:12 PM, "Parrot Raiser" <1parr...@gmail.com> wrote:
> In this article, "Every Simple Language Will Eventually End Up Turing 
> Complete"
> https://solutionspace.blog/2021/12/04/every-simple-language-will-eventually-end-up-turing-complete
> the author points out an unfortunate tendency for "simple" languages
> to accrete features and morph into misshapen monsters.

Interesting article; thanks for the pointer.

> Could Raku's grammars provide a way to express the unique features
> of a DSL while using the extra features from a carefully considered 
> framework?

My two ¢: I agree with Matthew that we'll be there soon, but that we that
we're not there yet – and won't be until we have full support for Slangs.

If you're interested in this sort of thing, you might enjoy reading about
Language Oriented Programming, 
https://en.wikipedia.org/wiki/Language-oriented_programming
if you haven't previously.  In particular, I think the book Beautiful Racket
https://beautifulracket.com/ is pretty fascinating.

(And I'll add that, once Slangs are stable, we'll have some catching up to
do to be as good at DSLs and similar projects as Racket is.  But I think
we have the potential to be even better (maybe by a lot!))

-codesections

Re: coercion

[Daniel Sockwell]

> The question now is that I can't find anything about COERCE in the 
> documentation. 

Yeah, COERCE definitely should be documented but just hasn't been yet.

There's a raku/doc issue about needing to add it 
(https://github.com/Raku/doc/issues/3807)
but unfortunately none of us has done so yet :(  That issue does link to a 
several blog
posts that explain the new coercion protocol – you might find those useful and 
you or
anyone else might also be able to adapt them into a great doc PR.

-codesections

Re: file format extensions

[Daniel Sockwell]

+1 from me too.  I'd also add test files to the list, which have at least .t 
and .rakutest 
(with the latter being preferred AFAK, so that GitHub will start highlighting 
them correctly).
I'm not sure if there are other acceptable extensions for test files, though?

Re: the MAIN questions

[Daniel Sockwell]

> * I'm pretty sure i saw something like :!$test to express Bool :$test = False.
> Did i just dreamed about it ?

You sort of dreamed it.  :!test passes test => False as a Pair, which means 
$test = False.
But that's syntax for calling the fn, not declaring it.  You could do Bool() 
:$test=0, but
imo that's not readable enough to be worthwhile. (In my own code, I typically 
write 
Bool :$test=False without spaces for the default value (even though I use them 
when `=` is
assignment rather than a default) and I find that clearer).

> * more importantly, is the a better choice than
> 
> +@files or @files = ('-');
> my $argfiles = IO::ArgFiles.new(@files);
> . for $argfiles.lines

The tighter precedence of || lets you inline the first line:

my $argfiles = IO::ArgFiles.new(@files || '-');
   . for $argfiles.lines

Or the whole thing, if you prefer:

. for IO::ArgFiles.new(@files || '-');

> This would be fair enough in any other languages but the whole thing looks
> unelegant in a raku code.

The other change I'd suggest for additional elegance (at least imo) is to put
the help text for each flag/option on the same line, either by putting it after
with #= or by using an embedded comment.  Here's the script with those changes:

   sub MAIN (
   #|[don't fix for real, just show the diff]  Bool :$diff=False,
   #|[input files (stdin by default or with explicit '-')] *@files ) {
   . for IO::ArgFiles.new(@files || '-').lines;
   }


Hope that helps!

-codesections

Re: junctions with given/when

[Daniel Sockwell]

Hi Larry,

I have a follow up question based on your May 31 email that I'm hoping
you may be able to answer.  In that email, you wrote:

> In my opinion, the most consistent approach is to disallow any
> autothreading of the argument to .ACCEPTS, such that
> 3.ACCEPTS(any(3,4)) simply returns False.…  I think treating the
> unrecognized $other as a raw Mu returning False (rather than a
> threadable Any returning a junction) is the most consistent, if not
> always in line with everyone's expections, which are not consistent.
> :)

I did some digging into why 3.ACCEPTS(any(3)) currently returns True,
and it turns out that it does so because you spec'd and implemented it
that way. The Roast test is at github.com/Raku/roast/commit/53f468 and
the implementation is at github.com/rakudo/rakudo/commit/28a769 – and
that commit has the message

> This is probably how most people will expect smartmatching to work.

Of course, you're free to change your mind – some rules never change :)

But I'd like to understand if this _is_ a deliberate change in your
thinking and, if so, what changed your mind.  From where I stand, the
logic from 2015-Larry is pretty convincing, but is sounds like you no
longer agree with that guy>  I'd be very interested to know what
convinced you.

Thank you in advance,

Daniel

Re: junctions with given/when

[Daniel Sockwell]

Hi Larry,

I have a follow up question based on your May 31 email that I'm hoping
you may be able to answer.  In that email, you wrote:

> In my opinion, the most consistent approach is to disallow any
> autothreading of the argument to .ACCEPTS, such that
> 3.ACCEPTS(any(3,4)) simply returns False.…  I think treating the
> unrecognized $other as a raw Mu returning False (rather than a
> threadable Any returning a junction) is the most consistent, if not
> always in line with everyone's expections, which are not consistent.
> :)

I did some digging into why 3.ACCEPTS(any(3)) currently returns True,
and it turns out that it does so because you spec'd and implemented it
that way. The Roast test is at github.com/Raku/roast/commit/53f468 and
the implementation is at github.com/rakudo/rakudo/commit/28a769 – and
that commit has the message

> This is probably how most people will expect smartmatching to work.

Of course, you're free to change your mind – some rules never change :)

But I'd like to understand if this _is_ a deliberate change in your
thinking and, if so, what changed your mind.  From where I stand, the
logic from 2015-Larry is pretty convincing, but is sounds like you no
longer agree with that guy>  I'd be very interested to know what
convinced you.

Thank you in advance,

Daniel

Re: callbacks with placeholder vars

[Daniel Sockwell]

I just submitted a PR based on this useful thread.
https://github.com/Raku/doc/pull/3942

Thanks to you both!

(Also, apparently $:a has the same behavior – after the first time, you 
can use $a )

Re: [naive] hash assingment

[Daniel Sockwell]

To expand slightly on what Clifton said, the reason that

> %a = %a.map: { .sqrt };
> # (1 1.4142135623730951 1.7320508075688772 2 2.23606797749979)

does what you mean but 

> %a{'column1'} ==> map( { .sqrt } )
> # (2.23606797749979)

does not is that the method .map maps over *each item* in the Array, whereas
==> map maps over the Array as *one collection*.  When taking the square root,
an Array needs to be treated as an number, which for Raku means treating it as 
a count of how many elements it has (i.e., its length).

So `%a{'column1'} ==> map({.sqrt})` is the same as 
`%a{'column1'}.elems.map({.sqrt})`

If want to map over each item in the Array when using the ==> operator, you 
need to
slip the items out of the Array before feeding them on.  You can do that with 
either
of the following (equivalent) lines:

> %a{'column1'}.Slip ==> map({.sqrt});
> |%a{'column1>'}==> map({.sqrt});

(Also, you may already know this, but when the keys of your hash are strings, 
you 
can write %a instead of %a{'column1'}  )

Hope that helps!

–codesections

Re: Buf to Str

[Daniel Sockwell]

Hi Paul,

If you _do_ want/need to work with C-style null-terminated strings, you can use 
the (core)
NativeCall library.  So, given your example:

> my Buf $b .= new([72, 105, 0, 32, 97, 103, 97, 105, 110, 0]);
> say $b.decode;
> I would expect this to print 'Hi'.
> 
> Instead it prints 'Hi again'.

You can write:

   use NativeCall;
   say nativecast(str, $b) # prints 'Hi'

Hope that helps!

– codesections

Re: File::Find using a junction with exclude

[Daniel Sockwell]

> Oh, and WAT is [short for] "Weird/will Ass Thing"?

No, it's not an abbreviation for anything – it's the word "what", but 
pronounced in a way that
indicates the speaker is surprised/confused. More specifically, it's a 
reference to the WAT talk (a
really good one, even if it is about a different language)
https://www.destroyallsoftware.com/talks/wat

(All of that is pretty much strait from the glossary, by the way)
https://docs.raku.org/language/glossary#index-entry-WAT

– codesections

Re: File::Find using a junction with exclude

[Daniel Sockwell]

> but what's that cabbage thing before $c?

It's the Atomic Symbol, U+269B. (Tangent: when looking up that unicode value, I 
learned
that Unicode puts the atomic symbol in the Religious Symbols subcatigory. 
Slightly troubling!)

Here, it's being used as part of the atomic prefix increment operator,
https://docs.raku.org/type/atomicint#prefix_++⚛ (As Vadim already mentioned).

That operator is exactly like the regular prefix ++, except that it's 
guaranteed to avoid 
race conditions in multithreaded use.  It's appropriate to use with Junctions, 
because they're
theoretically multitheadable.  On the other hand, they *aren't* yet 
multithreaded in any 
implementation, so for now

my $c = 0;
sub foo($) { ++$c }('a'|'b,b'|'c');
say $c;

works just as well (though the semantics are technically wrong!)

> Also worth noting that the hyper-op is needed here because pointy blocks are 
> not auto-threaded
> over junctions and take them as-is

Interesting – I didn't realize that.  Is the hyper op the only thing that 
triggers auto-threading
for Blocks?

Here's a slightly different take on the same basic idea, which avoids leaking 
$c:

{my atomicint $len; sub ($) { ++⚛$len }($_); $len}('a'|'b,b'|'c')





May 24, 2021 10:11 AM, "Andy Bach"  wrote:

> my atomicint $c = 0;
> sub foo($) { ++⚛$c }('a' | 'b,b' | 'c');
> say $c;
> 
> I was sort of hanging on by my fingertips (this completely lost me:
> 
>> Or, taking about tricks:
> 
> ('a' | 'b,b' | 'c')».&(-> $ { ++⚛$c });
> 
> ) but what's that cabbage thing before $c? Oh, and WAT is" Weird/will Ass 
> Thing"?
> 
> ___
> 
> From: Vadim Belman 
> Sent: Monday, May 24, 2021 8:53 AM
> To: perl6-users 
> Subject: Re: File::Find using a junction with exclude
> CAUTION - EXTERNAL:
> 
> Still ugly but much more reliable trick would be to use a sub and a counter 
> variable:
> 
> my atomicint $c = 0;
> sub foo($) { ++⚛$c }('a' | 'b,b' | 'c');
> say $c;
> 
> Or, taking about tricks:
> 
> ('a' | 'b,b' | 'c')».&(-> $ { ++⚛$c });
> 
> Apparently, this one is not ugly by semantics, but by its notation too. Also 
> worth noting that the
> hyper-op is needed here because pointy blocks are not auto-threaded over 
> junctions and take them
> as-is:
> 
> -> $v { say $v.WHAT }(1|2); # (Junction)
> 
> Best regards,
> Vadim Belman
> 
>> On May 24, 2021, at 8:42 AM, Daniel Sockwell  wrote:
> 
> It can be done without the EVAL:
> 
> any('a', 'b', 'c').raku.substr(4, *-1).split(',').elems
> 
> 3
>> Yeah, but only at the cost of some fragility:
> 
> any('a', 'b,b', 'c').raku.substr(4, *-1).split(',').elems
>> 4
>> 
>> I suppose you could do:
> 
> any('a', 'b,b', 'c').elems.raku.substr(4, *-1).split(',').elems
>> 3
>> 
>> but I'm not sure that's _that_ much better than EVAL – either way, we're 
>> depending on the Str
>> representation of inherently non-Str data, which seems like the main sin of 
>> EVAL.
>> 
>> – codesections
> 
> CAUTION - EXTERNAL EMAIL: This email originated outside the Judiciary. 
> Exercise caution when
> opening attachments or clicking on links.

Re: File::Find using a junction with exclude

[Daniel Sockwell]

> For example, you can't get a count of the number of elements in a junction

Well, if you're willing to stoop to ugly enough hacks, there's _always_ a 
way :D 

any('a', 'b').raku.substr(3).EVAL.elems # OUTPUT «3»

> My guess would be that the `ACCEPTS` method for a Junction
is special cased to handle the junction

I'm not sure that it's all _that_ much of a special case – it seems like
it mostly follows from the fact that ~~ *both* calls .ACCEPT *and* creates
a boolean context 
(https://docs.raku.org/language/contexts#index-entry-Boolean_context)

In other words, `'e' ~~ 'e'` is _not_ technically equivalent to `'e' eq 'e'`
– it's actually equivalent to `?('e' eq 'e')`.  Of course, in that case the
boolean context didn't make a difference because the comparison already 
returned a Bool.  But it does make a difference in the Junction case:

any('d', 'e', 'f') ~~ 'e';
# is the same as
?(any('d', 'e', 'f') eq 'e');

And, indeed, both return True.

Hope that helps at least a bit!

– codesections

Re: Please create a Raku community channel

[Daniel Sockwell]

I agree with the points Vadim and JJ made: There's a good chance that having a 
more official 
communication channel would _not_ have prevented surprise here, since the 
amount of progress 
on the a potential docs redesign seems to have taken many people (including 
me!) by surprise.
I guess that's what happens when our community has "forgiveness >> permission" 
as a core value!

That said, I also agree with Vadim that we should have a better way to 
communicate things like
this,
even if it wouldn't have been relevant in this particular case. In fact, we 
theoretically do: our 
website lists the perl6-announce list, which is supposed to be "low traffic (a 
few emails a
month)".
https://raku.org/community

Looking at the archive for that list, it has been **very** low traffic indeed: 
the last message was

sent in 2015. So we clearly haven't been using it, and starting now (when we're 
about to finally 
move on to raku-* mailing lists) probably doesn't make much sense. But, once we 
do, making an
effort
to actually use the raku-announce list seems like a good way to address this 
issue.

Finally, Richard, in the interest of not taking you by surprise again on the 
same topic, I wanted to
mention that, inspired by the proposed doc site redesign and your comments 
about the broader topic,
I'm now working on a proof of concept along the same lines (because I have a 
slightly different vision
of what a redesigned website might look like, but don't think I can communicate 
it without a POC).  I 
hope to be able to share more details in the coming days.

Best,
Daniel / codesections

Re: Find Packages with prefix ...

[Daniel Sockwell]

Hi Paul,

That's an interesting question, and I have a few thoughts below.  Before I get 
to those, I wanted
to point out an issue with the way you started your email with "Hey Gents": the 
Raku community 
includes many talented women, and I'd love to see it include more.

On to the technical question:

> Given this, I'd like the main program to perform a prefix search of installed 
> modules with that
> namespace as a prefix, load said modules it finds, perform callbacks that I 
> would designate as
> being required to successfully load the module, etc.

I _believe_ something like this should be possible with 
CompUnit::Repository::Installation, or 
maybe with CompUnit::RepositoryRegistry.  I say "believe" both because I 
haven't tried it myself
and because the documentation for CompUnit isn't yet very complete – indeed, 
::RepositoryRegistry
seems to be entirely undocumented.

The docs at 
https://docs.raku.org/type/CompUnit::Repository::Installation#method_candidates 
might
be a good starting point, but this is unfortunately an area that will probably 
take a bit more 
digging in the source. If you find a good solution, please let us all know – as 
I said, it's an
interesting question.

I hope that was helpful!

Re: Module Documentation

[Daniel Sockwell]

Richard Hainsworth  wrote:
> My suggestion is that some formal decision is made about documentation for 
> Raku modules, that some
> documentation good practices are put together and included in the Modules 
> page.


I think that this is a great idea (and that your suggestions afterwords are a 
good start).  Maybe the
next step would be to open an issue in the Problem Solving repo[0]?  To my 
knowledge, that's the main
way for the Raku community to make formal decisions of this nature.

[0]: https://github.com/Raku/problem-solving

Re: 'CALL-ME' Math problem?

[Daniel Sockwell]

Kevin Pye  wrote:
> Just because mathematics allows an implied multiplication doesn't mean Raku 
> does -- in fact I can't
> think of any programming language which does.

As a (potentially) interesting side note, while Raku doesn't provide implied 
multiplication, it _is_ 
one of the few programming languages that would let you implement something 
very similar yourself:
   sub infix:«\c[INVISIBLE TIMES]» { $^a × $^b }

This would let you write `say 60÷5(7−5)` (with an invisible character between 
the `5` and the `(` )
and get the expected result.

Doing so would, of course, be a very bad idea.  But still, you _could_.

Source:
https://perl6advent.wordpress.com/2017/12/01/the-grinch-of-perl-6-a-practical-guide-to-ruining-christmas/

Re: list of all raku classes?

[Daniel Sockwell]

> Is there a convenient way to get a list of all classes built-in to Raku?

Short answer:
raku -e '.say for (|CORE::, |UNIT::, |OUTERS::, |MY::).grep({ .key eq 
.value.^name }).grep({ .value.HOW.^name eq "Perl6::Metamodel::ClassHOW" 
}).map(*.key).unique'

Somewhat longer answer:
https://stackoverflow.com/questions/44861432/is-there-a-way-to-get-a-list-of-all-known-types-in-a-perl-6-program

I hope that helps!

-codesections