Re: A natural opportunity for Raku?

[Matthew Stuckwisch]

Yes, absolutely.  

There were some early examples with Tony O'Dell's inline SQL module. It doesn't 
actually check the syntax, and just passes off everything between 'sql' and 
';'.  You can see it at .  I'm sure it 
could be updated today to check off some of its current limitations, but it was 
more of a "hey, this can be done" module.

Recently, I made a test module wherein BASIC was provided as a language for 
methods that could be used just like traditional Raku methods.  
.  Both Fernando Correa de Oliveira 
and I have been working on (separate) regex-like slangs for specific purposes, 
and you can definitely expect to see some more stuff coming from us in the near 
future.

The main thing holding this back is the difficulty switching between languages. 
 You'll notice that it's possible to easily slip between all three of Raku's 
languages (main, regex, and Q).  For instance / regex { main: say 'q lang' } /. 
 At the moment, there's no easy way to enable that in slangs at the moment, but 
—and this is key— it's coming.  As soon as Rakudo can be run fully on RakuAST, 
I will be able to quickly enable the following syntax in BASIC (no, seriously, 
it'll be a 3-5 line modification, it will be that easy):

method-basic foo {
10 LET A = { $*RAKU.version ~~ /\d+ {say "I'm in the Q lang in Raku v$/ 
in Regex in Raku in BASIC in Raku" }/; +~$/ }
20 LET B = A * 10;
30 PRINT B
}

With the printed output being
 
I'm in the Q lang in Raku v6 in Regex in Raku in BASIC in Raku
60

All of the same syntax checking niceties that Raku has could be made available 
in any DSL created for Raku (for instance, in that BASIC example, compilation 
will fail —with an a message— if the line numbers don't go in order), it'd just 
be on the developer to provide them.

I'm fairly certain that DSLs were the main draw of both slangs and the 
grammars, it's just taken a while for us to get there.  But the light is at the 
end of the tunnel finally.

Matéu

> On Feb 12, 2022, at 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. 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?

Re: about binary protocol porting

[Matthew Stuckwisch]

The SNES compiler write ups reminded me I need to get back into creating a 
made-for-binary regex system.  Once I get done with some other projects I'm 
knee deep in, I'll sit down to really get a feel for RakuAST and then it'll be 
all go from there (and of course, as always, I welcome comments/feedback on the 
proposal gist 
 

One of the main things that I've found with doing binary stuff is it's 
important to get very comfortable working with the various classes related to 
working with binary data: Blob, Buf, and likely native integers/arrays.  The 
latter can be a bit tricky to work with as some things work a bit differently.  
Once you get the hang of it though, it's not too bad.

Also, definitely feel free to reach out on IRC -- while it might take some time 
to get an answer (especially if most are sleeping), stick around and we are 
generally pretty good about answering questiosn and problem solving / helping 
with the language.

Matéu


> On Dec 29, 2021, at 5:41 PM, Ralph Mellor  wrote:
> 
> On Wed, Dec 29, 2021 at 1:32 AM Jon Smart  wrote:
>> 
>> I plan to port a binary protocol client to perl6/raku.
>> I have zero experience on this. Where should I get started?
> 
> How well do you know programming, and Raku, and is the
> protocol a standard one you can link to with several existing
> implementations?
> 
> If the main motivation is just getting stuff done, consider using
> an existing implementation of the protocol. This will of course
> mean you'll have a dependency on that implementation, plus
> whatever PL it's written in, plus the Inline for that PL, but that
> can mean a working solution in a few minutes, maybe a few
> hours.
> 
> A complementary or alternate strategy if you're willing to wait
> until the time is right would be to wait for alatennaub to get far
> enough with their binary regex effort:
> 
> https://www.reddit.com/r/rakulang/comments/qqcnzr/binary_regex/
> 
> https://www.reddit.com/r/rakulang/comments/rm2tve/
> writing_a_snes_assembler_compilerdisassembler_day/hpjziq4/
> 
> Then you could (presumably) use that.
> 
> (And/or you could collaborate with them to accelerate things.)
> 
> --
> love, raiph

Re: Date.new("2024-02-29").later( :1year)

[Matthew Stuckwisch]

I don't think there is a standard. But the same will happen with
.later(:1month) on a month with 31 days where the day is 31, or a DateTime
with a leapsecond advancing by a unit larger than a second. It minimizes
the changes in nominal units.

On Mon, Dec 13, 2021, 05:23 rir  wrote:

>
> REPL says:
> > Date.new("2024-02-29").later( :1year);
> 2025-02-28
>
> Is the following some standard?
>
>
>

Re: Why does .new initialize?

[Matthew Stuckwisch]

In general, the idea of initialized doesn't mean a lot in Raku, at least
not at the language level.

At any given time, any variable has a value. By default, if you've typed a
variable, it's initially set to the type itself (Any is the default type,
so the default default value). The only exceptions are native types which
are either 0 or the empty string, depending, or if you've added a trait to
override the default value. Note the following, which may be a bit
surprising to you:

my Int $a;
my $b = Int;
my $c;
say $a === $b === Int; # True
say $c === $a; # False

$c's value here is (Any), but both $a and $b are (Int).

.new calls self.bless, which handles all of the allocation stuff behind the
scenes, but —importantly— each attribute, like any variable, will always
have a value (it just might not be defined), such that

class Foo {
has Rat $.bar;
}
say Foo.new.bar === Rat; # True
say Foo.new.bar.defined; # False

In some classes, undefined values for those attributes may not make sense,
and each can make its own decisions how to handle when lacking defined
values.

Hope that makes sense,

Matéu

On Mon, Jul 19, 2021, 19:10 Peter Scott  wrote:

> Yes.  I'm agnostic on this point, but there was a time when some prominent
> Perl contributors were dogmatic about it and I didn't know how widespread
> it was.
>
> Peter
>
> On 7/19/2021 10:06 AM, Vadim Belman wrote:
>
>
> Let me guess. The school prohibits object self-initialization? It has to
> be done by external code?
>
> Best regards,
> Vadim Belman
>
> On Jul 19, 2021, at 1:00 PM, Peter Scott  wrote:
>
> On 7/19/2021 1:24 AM, Elizabeth Mattijsen wrote:
>
> If .new wouldn't initialize a type to its basic instantiation, what would
> be the point of .new then?
>
> FWIW, the same goes for:
>
> dd Int.new;  # 0
> dd Num.new;  # 0e0
> dd Complex.new;  # <0+0i>
> dd Str.new;  # ""
>
> If you want to leave it undefined, don't call .new on it?
>
> *confused*
>
>
> Only that there's a vocal school of thought in O-O that says new() should
> only allocate memory and never put anything in there.  Now I know that Raku
> doesn't subscribe to that I have no problem.
>
> Cheers,
> Peter
>
>
>
>

Re: searching for a blog

[Matthew Stuckwisch]

I think it was Daniel Sockwell (codesections) that played around with it. See 
the blog entry at  and the 
associated Pod::Literate module at 
 .

There's also my Test::Inline (I know I posted about it somewhere but I don't 
believe it was on a blog) which can be found at 
, but it doesn't integrate POD6.

Matéu


> On Jul 18, 2021, at 09:19, Marcel Timmerman  wrote:
> 
> Hi,
> 
> I am searching for a blog of someone who explained how to write testing code 
> next to the programs code. I believe the testing code was written in pod 
> documentation. I am interested in the way it was done but can't find the blog 
> anymore.
> 
> Does anyone have a link to the blog for me?
> Thanks,
> Marcel

Re: Buf to Str

[Matthew Stuckwisch]

Another way to do this could be to just create your own method.

my method decode-c(Blob:) { self.subbuf(^self.first(0,:kv)[0]).decode }
my $string-with-zero = Buf.new: 72, 101, 108, 108, 111, 0, 32, 119,
111, 114, 108, 100, 33;

say $string-with-zero.decode;
say $string-with-zero.

The output of the last two lines would be "Hello World!" and "Hello",
respectively (although with a U+ character after the first o).  If
used frequently enough (or one dislikes the .& syntax), it could also
be added into Blob/Buf via an augment.

El mié, 9 jun 2021 a las 10:47, Daniel Sockwell
() escribió:
>
> 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: locations relative to script location

[Matthew Stuckwisch]

Using $*PROGRAM.parent for the directory of the current script is what I've 
always used, and it works well.

Note that if you do .add('../../../'), you may need to also call .resolve at 
some point, but I generally just use .parent several times.  (I think at worst 
case I've only ever gone up two levels).  You can also use .parent(3) as a 
shorthand for .parent.parent.parent or .add('../../../').resolve

Also this just gave me the idea for having some fun with FALLBACK

IO::Path.^add_fallback(
anon method condition ($name) { 
so $name ~~ /^(great)*grandparent$/ 
},
anon method calculator ($name) { 
$name ~~ /^(great)*grandparent$/;
my $levels = 2 + $0;
anon method { self.parent($levels) }
}
);

my $file = IO::Path.new: "/etc/foo/bar/abc/xyz.txt";

say $file.parent;  # "/etc/foo/bar/abc".IO
say $file.grandparent; # "/etc/foo/bar".IO
say $file.greatgrandparent;# "/etc/foo".IO
say $file.greatgreatgrandparent;   # "/etc".IO
say $file.greatgreatgreatgrandparent;  # "/".IO



> On Mar 29, 2021, at 7:50 PM, Joseph Brenner  wrote:
> 
> I'm looking for the canoncial way to get the location
> of the currently running script (similar to perl's
> FindBin), so that I can specify other locations
> relative to the script location.
> 
> This does what I want, but I see that the docs say
> that it's deprecated:
> 
>  my $loc = $*PROGRAM.chdir('..');
>  chdir( $loc );
> 
> The docs suggest using the .add method instead,
> But this does not at all do what I want:
> 
>  my $loc = $*PROGRAM.add('..');
>  chdir( $loc );
> 
> That tries to change the current location to:
> 
>  "/home/bozo/bin/mah_script.raku/.."
> 
> And that fails, because the script name isn't a directory.
> 
> Note: I could of course do my own surgey on $*PROGRAM
> to get the path to the script, but that at least used
> to be regarded as poor form for portability (e.g.  the
> windows backslash separator vs the unix slash).
> 
> This works fairly well:
> 
>my $dir = $*PROGRAM.dirname;
>chdir( $dir );
> 
> But it's a little disappointing I can't do this:
> 
>my $dir = $*PROGRAM.dirname.add('../..');
> 
> Because apparently "dirname" literally returns the
> name in string form:
> 
>  No such method 'add' for invocant of type 'Str'
> 
> Ah, but I guess this works:
> 
>my $new_loc = $*PROGRAM.parent.add('../../dat');
>chdir( $new_loc );
> 
> So, does that look anything like the Right Way?

Re: Module Documentation

[Matthew Stuckwisch]

So here's my 2¢, which will probably be followed up with some actual 
development of stuff (I do put my money where my mouth is… although it might 
take me a while to save up to spend it ha).  Some of the minor details could, 
of course, easily be adjusted, so don't fixate too much on them.

Right now, it is true that many of us use README.md for github.  Some people 
write this one by hand (I'm guilty of it), others (lizmat, for instance) 
generate this from their *.rakumod file.

We can do a lot more with POD6 than we can with MD (as POD6 encodes things more 
semantically than MD), so we should encourage pushing towards using that, and 
then using a script to generate the MD (or HTML, in the case of a website).  
The following would be my rough proposal:

(1) Standard the function/meaning of reserved blocks (e.g. =TITLE vs =NAME, 
when to use one or the other or how they should be different).  Perhaps as 
larger projects like Red or Intl document extensive/larger documents, we can 
see what patterns might emerge and evaluate.

(2) Just as we have /t, /lib, and /bin as standard module folders, use /doc[s] 
as a default space for documentation. For those that prefer not to use inline 
documentation, their pod6 files would reside here (which could also be 
identically-named rakumod files, esp. when wanting to have declarator pod 
included).  In any case, .md files could be autogenerated here for use on 
github, or .html for elsewhere.  README.md (or index.html, for webpages) could 
be autogenerated for github based on 4b.

(3) Localized documentation in /docs/local/zzz-XX.  The localized documentation 
could be made from a skeleton/fully stubbed file rakumod file (for declarator 
stuff) or from a standard pod6 file whose file names coincide with the docs (or 
lib) versions.  I'd be happy to do some of the work here, as I plan to localize 
a fair bit of my documentation for certain modules.

(4) To help with the above, several new META6.json keys:
a. docs-lang for the language of inline documentation (en default).
b. docs-root for the module whose docs will serve as a front page (e.g. 
README.md or as the first text on aggregator pages)
c. docs-ext for an outside link to documentation, which would be a fallback 
to any other documentation and contrasted with a general website.

For 4c, these could be added to the support entry, as support->docs and 
support->website, and the docs-lang/docs-root could be under a single entry 
with two subkeys.

Anyways, lengthy 2¢ but there we go :-) 

Matéu

> On Mar 2, 2021, at 08:25, Richard Hainsworth  wrote:
> 
> Hi, I want to create a system that will show documentation about Raku Modules 
> that I have installed.
> 
> There does not seem to be a Documentation standard, or best practice, for 
> Raku modules.
> 
> Hence the following post.
> 
> In the Modules documentation in the Language section of the Raku 
> documentation, there is a single mention of README.md, but only that it is 
> needed by github. There is no indication about what should be in README.md
> 
> As a user of Raku, this does not matter much to me in practice, as when I 
> need to understand something, I look at the code on the repository. But it 
> can be a hassle going to Modules.raku.org, finding the module, going to the 
> repo, finding where the information is, etc. I do NOT try and find the 
> information that has been installed by zef because the location names are not 
> human friendly. I understand the reasoning there, and do not suggest any 
> change. But it is not easy to find documentation on locally installed 
> modules, even though the information is there.
> 
> Even the "zef --open browse  source" command opens a browser to the 
> internet repo, not to the local installation. There is no "zef documentation 
> entity" or "zef README entity" command. I am NOT complaining about zef 
> because the problem is not with zef, per se, but with the absence of a 
> documentation standard (I think).
> 
> I wanted to incorporate a page with documentation of modules in the 
> Collection-Raku-Documentation system I have just released.
> 
> But I do not see how to do this.
> 
> Most Raku modules have a README.md, which is required because of github 
> requirements. Although the README's of some modules leave a great deal to be 
> desired.
> 
> Many modules have extensive POD6 inside the main 'lib/module.pm6' file (where 
> 'module' obviously is a placeholder for this email).
> 
> There is an issue on the GTK::Simple repo, which I am now the maintainer of, 
> for more documentation. Actually, I learnt how to use GTK::Simple by looking 
> at the examples in the repo, which have lots of explanation. But the 
> README.md is appalling. However, an unanswered question is where would I put 
> a documentation file when I write it, so that it is useful for users wanting 
> to understand more.
> 
> In the modules I am now developing, I have a README.pod6 file, which I 
> convert to the README.md file 

Re: 'CALL-ME' Math problem?

[Matthew Stuckwisch]

But why do that when you can add a CALL-ME to the number classes that does
multiplication? 

Int.^add_fallback(
{$^i.defined && $^m eq 'CALL-ME'},
-> $, $ { * * * }
);

say 5(4); # 20



On Tue, Mar 2, 2021, 09:08 Daniel Sockwell  wrote:

> 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: dimensions in a multidimensional array

[Matthew Stuckwisch]

I think he meant doing something like this (with fuller handling for out of 
bounds, exceptions throwing, slices, etc):

role Shaped[*@dimensions] {
has @!multipliers = 
@dimensions.reverse.produce(&[*])[0..*-2].reverse.Slip, 1;

method AT-POS(*@indices where all @dimensions Z> @indices ) { 
self.List::AT-POS( [+] @indices Z* @!multipliers ) 
}
}

In this way, you could read in serial data with a bit less work by shaping it 
after the fact, e.g. 
   
my @foo = $fh.slurp.split($delimiter);
@foo does Shaped[ … ];



> On Feb 5, 2021, at 12:31 PM, Timo Paulssen  wrote:
> 
> Shaped Arrays and Native Shaped Arrays already use one contiguous blob to 
> store all their data; in Shaped Arrays that's an array of pointers to the 
> stored objects, in a Native Shaped Array it'll be like a big array of 32bit 
> integers or whatever you have.
> 
> Regards
>   - Timo
> 
> On 05/02/2021 16:48, yary wrote:
>> This got me interested in 
>> https://docs.raku.org/language/list#index-entry-Shaped_arrays
>> 
>> and I find myself wanting to implement a role "Shaped" and applying it to 
>> List, for an immutable shaped list, whose implementation packs its elements 
>> for o(1) lookup... on my ever-lengthening to-do list
>> 
>> -y
>> 
>> 
>> On Fri, Feb 5, 2021 at 10:06 AM Elizabeth Mattijsen  wrote:
>> > On 5 Feb 2021, at 15:49, Theo van den Heuvel  wrote:
>> > I cannot seem to find an idiomatic way to get the dimensions of a 
>> > multidimensional array,
>> > other than by looking at the size of the first row and column, with 
>> > @m[0;*].elems and @m[*;0].elems.
>> > Am I missing something in the docs?
>> 
>> If it's a shaped multidimensional array, you can call the .shape method
>> 
>> my @a[3;3;3];
>> dd @a.shape;   # (3,3,3)
>> 
>> If it is not, then your workaround appears the way to do it.

Re: \n and array question

[Matthew Stuckwisch]

The <…> and «…» constructors break on whitespace.

So  will actually produce the following array:

["a,b,c,d,e,f"]

It's only one item.  If we placed space after the comma, that is, , you'd get a six item list, but with the commas attached to all but the 
final:

   ["a,", "b,", "c,", "d,", "e,", "f"]

By replacing the commas with spaces, e.g., , you allow it to break 
into ["a", "b", "c", "d", "e", "f"]

Matéu

> On Nov 14, 2020, at 14:12, ToddAndMargo via perl6-users 
>  wrote:
> 
> On 2020-11-14 11:08, Curt Tilmes wrote:
>> On Sat, Nov 14, 2020 at 2:03 PM ToddAndMargo via perl6-users
>>  wrote:
>>> Just out of curiosity, why is the \n printed out literally here?
>>> p6 'my @x = <"aaa\n","bbb\n","ccc\n">; for @x {print @_};'
>> Your 'word quoting' <> is sort of like single quotes -- it keeps the
>> literal stuff.  You could
>> use <<>> which is more like double quotes,
>> Curt
> 
> or remove the commas.  I put everything in [0]
> 
> 
> $ p6 'my @x = ; for @x {print "$_\n";}'
> aaa\n
> bbb\n
> ccc\n
> 
> $ p6 'my @x = <>; for @x {print "$_\n";}'
> aaa
> bbb
> ccc
> 
> $ p6 'my @x = <>; for @x {print "$_";}'
> aaabbbccc
> 
> What am I missing?
> 
> -T
> 
> -- 
> ~~
> Computers are like air conditioners.
> They malfunction when you open windows
> ~~

Re: "ICU - International Components for Unicode"

[Matthew Stuckwisch]

In #raku it was mentioned that it would be nice to have a $*UNICODE variable of 
sorts that reports back the version, but not sure how that would be from an 
implementation POV.

I'm also late to the discussion, so pardon me jumping back a bit.  Basically, 
ICU is something that lets you quickly add in robust Unicode support.  But it's 
also a swiss army knife and overkill for what Raku generally needs (at 
whichever its implemented in), and also limiting in some ways because you 
become beholden to their structures which as Samantha pointed out, doesn't work 
for MoarVM's approach.  Rolling your own has a lot of advantages.

Beyond UCD and UAC (sorting), everything else really should go into module land 
since they're heavily based on an ever changing and growing CLDR, and even 
then, there can be good arguments made for putting sorting in module space too. 
 For reasons like performance, code clarity, data size, etc, companies have 
rolled their own ICU-like libraries (Google's Closure for JS, TwitterCLDR in 
Ruby, etc) running on the same CLDR data.  In Raku (shameless selfplug), a lot 
is already available in the Intl namespace.  There are actually some very cool 
things that can be done mixing CLDR and Raku like creating new 
character-class-like tokens, or even extending built ins — they just don't have 
any business being near core, just... core-like :-)

Matéu


PS: For understanding some of Samantha's incredible work, her talks at the 
Amsterdam convention are really great, and Perl Weekly has an archive of her 
grant write ups:
  Articles: https://perlweekly.com/a/samantha-mcvey.html
  High End Unicode in Perl 6: https://www.youtube.com/watch?v=Oj_lgf7A2LM
  Unicode Internals of Perl 6: https://www.youtube.com/watch?v=9Vv7nUUDdeA
  

> On Sep 29, 2020, at 3:14 PM, William Michels via perl6-users 
>  wrote:
> 
> Thank you, Samantha!
> 
> An outstanding question is one posed by Joseph Brenner--that
> is--knowing which version of the Unicode standard is supported by
> Raku. I grepped through two files, one called "unicode.c" and the
> other called "unicode_db.c". They're both located in rakudo at:
> /rakudo/rakudo-2020.06/nqp/MoarVM/src/strings/ .
> 
> Below are the first 4 lines of my grep results. As you can see
> (above/below), rakudo-2020.06 supports Unicode12.1.0:
> 
> ~$ raku -ne '.say if .grep(/unicode/)'
> ~/rakudo/rakudo-2020.06/nqp/MoarVM/src/strings/unicode_db.c
> # For terms of use, see http://www.unicode.org/terms_of_use.html
> # The UAXes can be accessed at http://www.unicode.org/versions/Unicode12.1.0/
> From http://unicode.org/copyright.html#Exhibit1 on 2017-11-28:
> Distributed under the Terms of Use in http://www.unicode.org/copyright.html.
> 
> 
> It would be really interesting to follow your Unicode work, Samantha.
> The ideas you propose are interesting and everyone hopes for speed
> improvements. Is there any place Raku-uns can go to read
> updates--maybe a grant report, blog, or Github issue? Or maybe right
> here, on the Perl6-Users mailing list? Thanks in advance.
> 
> Best, Bill.
> 
> W. Michels, Ph.D.
> 
> 
> 
> On Sun, Sep 27, 2020 at 4:03 AM Samantha McVey  wrote:
>> 
>> So MoarVM uses its own database of the UCD. One nice thing is this can
>> probably be faster than calling to the ICU to look up information of each
>> codepoint in a long string. Secondly it implements its own text data
>> structures, so the nice features of the UCD to do that would be difficult to
>> use.
>> 
>> In my opinion, it could make sense to use ICU for things like localized
>> collation (sorting). It also could make sense to use ICU for unicode
>> properties lookup for properties that don't have to do with grapheme
>> segmentation or casing. This would be a lot of work but if something like 
>> this
>> were implemented it would probably happen in the context of a larger
>> rethinking of how we use unicode. Though everything is complicated by that we
>> support lots of complicated regular expressions on different unicode
>> properties. I guess first I'd start by benchmarking the speed of ICU and
>> comparing to the current implementation.
>> 
>>