[Raku/old-design-docs] 07ac3b: rm broken link

[librasteve via perl6-language]

  Branch: refs/heads/master
  Home:   https://github.com/Raku/old-design-docs
  Commit: 07ac3bb2ab509a5143e5f99a0e9c32b823828fae
  
https://github.com/Raku/old-design-docs/commit/07ac3bb2ab509a5143e5f99a0e9c32b823828fae
  Author: librasteve <40125330+librast...@users.noreply.github.com>
  Date:   2024-01-18 (Thu, 18 Jan 2024)

  Changed paths:
M README.md

  Log Message:
  ---
  rm broken link


  Commit: a4c36c683dafdad0bb55996e78b66a1f48fc703c
  
https://github.com/Raku/old-design-docs/commit/a4c36c683dafdad0bb55996e78b66a1f48fc703c
  Author: librasteve <40125330+librast...@users.noreply.github.com>
  Date:   2024-01-18 (Thu, 18 Jan 2024)

  Changed paths:
M README.md

  Log Message:
  ---
  Merge pull request #128 from librasteve/master

rm broken link


Compare: 
https://github.com/Raku/old-design-docs/compare/63e44c363518...a4c36c683daf

Virtualmin and Webmin web hosting control panel are written in Perl 5

[Turritopsis Dohrnii Teo En Ming]

Subject: Virtualmin and Webmin web hosting control panel are written in Perl 5

Good day from Singapore,

I understand that Virtualmin and Webmin web hosting control panel are
written in Perl 5.

Source: In which perl framework is webmin written into?
Link: https://archive.virtualmin.com/node/36615

If I want to learn Perl programming language from scratch having
totally no knowledge of it, how long (in terms of months or years)
would it take before I can confidently and proficiently modify
Virtualmin and Webmin code?

Hopefully there is no steep learning curve.

Thank you.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore
1 Aug 2022 Mon
Blogs:
https://tdtemcerts.blogspot.com
https://tdtemcerts.wordpress.com

Re: Correct enum incantation?

[Fernando Santagata]

On Wed, May 5, 2021 at 6:00 PM William Michels via perl6-users <
perl6-us...@perl.org> wrote:

> Hello,
>
> I've been reading over an interesting Answer on StackOverflow by wamba:
>
> https://stackoverflow.com/a/67324175/7270649
>
> I started trying to explore enums on my own and quickly realized that
> method calls on enums are different from simple key/value pairs. For enums,
> calling a `.key` or `.value` or `.kv` method won't work. Instead one must
> use something like `.^enum_values` or `.^enum_value_list`.
>

Probably you need the new and shiny compiler ;)

> $*RAKU.compiler.version
v2021.04
> Month.keys
(oct dec aug jun mar apr feb nov jul may sep jan)
> Month.values
(11 6 9 2 5 7 3 12 8 4 10 1)
> .say for Month.kv
nov
11
jul
7
sep
9
jan
1
oct
10
mar
3
jun
6
apr
4
aug
8
dec
12
feb
2
may
5
-- 
Fernando Santagata

Re: Correct enum incantation?

[William Michels via perl6-language]

Thank you Fernando!

(still on Rakudo 2020.10 here).

On Wed, May 5, 2021 at 10:24 AM Fernando Santagata <
nando.santag...@gmail.com> wrote:

> On Wed, May 5, 2021 at 6:00 PM William Michels via perl6-users <
> perl6-us...@perl.org> wrote:
>
>> Hello,
>>
>> I've been reading over an interesting Answer on StackOverflow by wamba:
>>
>> https://stackoverflow.com/a/67324175/7270649
>>
>> I started trying to explore enums on my own and quickly realized that
>> method calls on enums are different from simple key/value pairs. For enums,
>> calling a `.key` or `.value` or `.kv` method won't work. Instead one must
>> use something like `.^enum_values` or `.^enum_value_list`.
>>
>
> Probably you need the new and shiny compiler ;)
>
> > $*RAKU.compiler.version
> v2021.04
> > Month.keys
> (oct dec aug jun mar apr feb nov jul may sep jan)
> > Month.values
> (11 6 9 2 5 7 3 12 8 4 10 1)
> > .say for Month.kv
> nov
> 11
> jul
> 7
> sep
> 9
> jan
> 1
> oct
> 10
> mar
> 3
> jun
> 6
> apr
> 4
> aug
> 8
> dec
> 12
> feb
> 2
> may
> 5
> --
> Fernando Santagata
>

Correct enum incantation?

[William Michels via perl6-language]

Hello,

I've been reading over an interesting Answer on StackOverflow by wamba:

https://stackoverflow.com/a/67324175/7270649

I started trying to explore enums on my own and quickly realized that
method calls on enums are different from simple key/value pairs. For enums,
calling a `.key` or `.value` or `.kv` method won't work. Instead one must
use something like `.^enum_values` or `.^enum_value_list`.

Can someone explain how `.^enum_values` or `.^enum_value_list` came to be
the **correct** incantation for enums, and why there is no equivalent
`.^enum_keys` or `.^enum_key_list` commands? Thank you, Bill.


> # In the Raku REPL (wamba's enum example 'Month')
> enum Month (jan => 1, |);
Map.new((apr => 4, aug => 8, dec => 12, feb => 2, jan => 1, jul => 7, jun
=> 6, mar => 3, may => 5, nov => 11, oct => 10, sep => 9))
>
> Month.^enum_values
{apr => 4, aug => 8, dec => 12, feb => 2, jan => 1, jul => 7, jun => 6, mar
=> 3, may => 5, nov => 11, oct => 10, sep => 9}
> Month.^enum_value_list
(jan feb mar apr may jun jul aug sep oct nov dec)
>
> Month.^enum_keys
No such method 'enum_keys' for invocant of type
'Perl6::Metamodel::EnumHOW'
  in block  at  line 4

> Month.^enum_key_list
No such method 'enum_key_list' for invocant of type
'Perl6::Metamodel::EnumHOW'
  in block  at  line 1

>
> #Random keyword attempts:
> Month.key
Invocant of method 'key' must be an object instance of type 'Mu', not a
type object of type 'Month'.  Did you forget a '.new'?
  in block  at  line 1

> Month>>.key
Invocant of method 'key' must be an object instance of type 'Mu', not a
type object of type 'Month'.  Did you forget a '.new'?
  in block  at  line 1

> Month.keys
()
> Month>>.keys
(())

Re: Performance of matrix arithmetic in Raku

[Timo Paulssen]

Hi,

raku doesn't have matrix operations built into the language, so you're 
probably refering to modules out of the ecosystem?


Math::Matrix seems to have everything implemented in pure raku, which 
you should not expect to outperform pure python without some 
optimization work.


Math::libgsl::Matrix is a NativeCall wrapper around the gnu scientific 
library, which you would expect to be fast whenever big tasks can be 
implemented as a single call into the library, and a bit slower whenever 
data has to go back and forth between raku and the library, though 
without measuring first, I can't say anything about the actual 
performance numbers.


It would be quite important to see whether the "python performance of 
matrix arithmetic" refers to NumPy, which i think has most of its code 
implemented in fortran, which i would naively expect to outperform code 
written in C.


Other than that, there's of course the @ operator in python which just 
does matrix multiplication i think? You would have to look at CPython to 
see how that is implemented.


On top of that, you'll of course also have to try the code in question 
with PyPy, which is very good at making python code go fast, and perhaps 
with Cython?


Hope this doesn't add too many more questions, and actually answers a 
thing or two?

  - Timo

On 09/02/2021 02:18, Parrot Raiser wrote:

There's a post online comparing Python's performance of matrix
arithmetic to C, indicating that Python's performance was 100x (yes, 2
orders of magnitude) slower than C's.

If I understand it correctly, matrix modules in Raku call GNU code
written in C to perform the actual work.

Does that make Raku significantly faster for matrix work, which is a
large part of many contemporary applications, such as AI and video
manipulation? If it does, that could be a big selling point.

Performance of matrix arithmetic in Raku

[Parrot Raiser]

There's a post online comparing Python's performance of matrix
arithmetic to C, indicating that Python's performance was 100x (yes, 2
orders of magnitude) slower than C's.

If I understand it correctly, matrix modules in Raku call GNU code
written in C to perform the actual work.

Does that make Raku significantly faster for matrix work, which is a
large part of many contemporary applications, such as AI and video
manipulation? If it does, that could be a big selling point.

Re: Checking for nil return

[Darren Duncan]

On 2020-12-29 6:26 a.m., Ruud H.G. van Tol wrote:

Basically, never mix error-state and return-value.
Rather use a different channel/dimension for each.


Such a separation can't be absolute though.  One needs to be able to user-define 
routines that implement additional generic Failure related features, and in that 
case they WOULD be normal arguments or return values.  And so the regular type 
system still needs to support having anything at all as an argument or return 
value. -- Darren Duncan

Re: Checking for nil return

[yary]

Moving the "can't catch Nil return, why is Nil also a failure?" question to
a Raku issue, https://github.com/Raku/doc/issues/3760

This got me going through Raku source code to see where Nil gets passed
through; this looks promising. rakudo/src/vm/moar/spesh-plugins.nqp line 308

# Allow through Nil/Failure
(nqp::istype($rv, Nil) || (nqp::istype($rv, $type) &&
...

Mostly for my own education, though if the discussion goes along the lines
of "let's make Nil not a failure" then I may look at a patch to make it so.

-y


On Wed, Dec 30, 2020 at 10:02 PM yary  wrote:

> This commit shows where Nil expanded from being "Absence of a value" to,
> alternatively, "a benign failure". Unfortunately I haven't found discussion
> on "benign failure" – semantics, use case, prior art, example, that sort of
> thing – and the commit doesn't elaborate.
>
> https://github.com/Raku/doc/commit/2b3c920ae9c37d14f76ab1eab236df2ec4f513ec
>
> I added a comment to that commit, which is now nearly 5 years old. Would
> be good to get a follow up from the committer!
>
> -y
>
>
> On Tue, Dec 29, 2020 at 9:28 AM Ruud H.G. van Tol 
> wrote:
>
>>
>> Basically, never mix error-state and return-value.
>> Rather use a different channel/dimension for each.
>>
>> And any value itself can have special state too, like "absence" and (via
>> its type) "has-default".
>>
>> On that docs-page, my stomach protested against the Nil/default pairing.
>> Now I need to think through why it (grumbled that it) is wrong.
>> (or not wrong: for performance reasons, it is good to support values
>> that can never be undefined)
>>
>> -- Ruud
>>
>>
>> On 2020-12-28 22:35, yary wrote:
>> > [...]
>> > Allowing Failure as a return always makes sense to me– every block
>> needs
>> > to be capable of passing along a failure, that's how the language is
>> > designed.
>> >
>> > On the other hand, Nil is not a Failure. Conceptually it is a lack of
>> an
>> > answer, similar to SQL's null concept.
>> >
>> > What's the usefulness of having Nil skip return type checking-
>> > specifically Nil and not its Failure descendents?
>> >
>> > This example under https://docs.raku.org/type/Nil
>> >  shows what I think is a
>> > less-than-awesome specification, and I am curious about the reasoning
>> > behind it being defined as valid
>> >
>> > suba( -->Int:D ) { return Nil }
>>
>

Re: Checking for nil return

[yary]

This commit shows where Nil expanded from being "Absence of a value" to,
alternatively, "a benign failure". Unfortunately I haven't found discussion
on "benign failure" – semantics, use case, prior art, example, that sort of
thing – and the commit doesn't elaborate.

https://github.com/Raku/doc/commit/2b3c920ae9c37d14f76ab1eab236df2ec4f513ec

I added a comment to that commit, which is now nearly 5 years old. Would be
good to get a follow up from the committer!

-y


On Tue, Dec 29, 2020 at 9:28 AM Ruud H.G. van Tol 
wrote:

>
> Basically, never mix error-state and return-value.
> Rather use a different channel/dimension for each.
>
> And any value itself can have special state too, like "absence" and (via
> its type) "has-default".
>
> On that docs-page, my stomach protested against the Nil/default pairing.
> Now I need to think through why it (grumbled that it) is wrong.
> (or not wrong: for performance reasons, it is good to support values
> that can never be undefined)
>
> -- Ruud
>
>
> On 2020-12-28 22:35, yary wrote:
> > [...]
> > Allowing Failure as a return always makes sense to me– every block needs
> > to be capable of passing along a failure, that's how the language is
> > designed.
> >
> > On the other hand, Nil is not a Failure. Conceptually it is a lack of an
> > answer, similar to SQL's null concept.
> >
> > What's the usefulness of having Nil skip return type checking-
> > specifically Nil and not its Failure descendents?
> >
> > This example under https://docs.raku.org/type/Nil
> >  shows what I think is a
> > less-than-awesome specification, and I am curious about the reasoning
> > behind it being defined as valid
> >
> > suba( -->Int:D ) { return Nil }
>

Re: Checking for nil return

[Ruud H.G. van Tol]

Basically, never mix error-state and return-value.
Rather use a different channel/dimension for each.

And any value itself can have special state too, like "absence" and (via 
its type) "has-default".


On that docs-page, my stomach protested against the Nil/default pairing. 
Now I need to think through why it (grumbled that it) is wrong.
(or not wrong: for performance reasons, it is good to support values 
that can never be undefined)


-- Ruud


On 2020-12-28 22:35, yary wrote:

[...]
Allowing Failure as a return always makes sense to me– every block needs 
to be capable of passing along a failure, that's how the language is 
designed.


On the other hand, Nil is not a Failure. Conceptually it is a lack of an 
answer, similar to SQL's null concept.


What's the usefulness of having Nil skip return type checking- 
specifically Nil and not its Failure descendents?


This example under https://docs.raku.org/type/Nil 
 shows what I think is a 
less-than-awesome specification, and I am curious about the reasoning 
behind it being defined as valid


suba( -->Int:D ) { return Nil }

Re: Checking for nil return

[Brad Gilbert]

The closest to null is actually an undefined type object

On Mon, Dec 28, 2020, 3:36 PM yary  wrote:

> Been thinking about this, and checked out the Rakudo repository to peek
> into the source.
>
> Allowing Failure as a return always makes sense to me– every block needs
> to be capable of passing along a failure, that's how the language is
> designed.
>
> On the other hand, Nil is not a Failure. Conceptually it is a lack of an
> answer, similar to SQL's null concept.
>
> What's the usefulness of having Nil skip return type checking-
> specifically Nil and not its Failure descendents?
>
> This example under https://docs.raku.org/type/Nil shows what I think is a
> less-than-awesome specification, and I am curious about the reasoning
> behind it being defined as valid
>
> sub a( --> Int:D ) { return Nil }
>
>
>
> -y
>
>
> On Sun, Dec 20, 2020 at 7:18 PM Brad Gilbert  wrote:
>
>> Nil is always a valid return value regardless of any check.
>>
>> This is because it is the base of all failures.
>>
>> On Sat, Dec 19, 2020, 8:17 PM yary  wrote:
>>
>>> Is this a known issue, or my misunderstanding?
>>>
>>> > subset non-Nil where * !=== Nil;
>>> (non-Nil)
>>> > sub out-check($out) returns non-Nil { return $out }
>>> 
>>> > out-check(44)
>>> 44
>>> > out-check(Nil)
>>> Nil
>>>
>>> ^ Huh, I expected an exception on "out-check(Nil)" saying the return
>>> value failed the "returns" constraint.
>>>
>>> The subtype works as I expect as an the argument check
>>>
>>> > sub in-check (non-Nil $in) { $in }
>>> 
>>> > in-check(33)
>>> 33
>>> > in-check(Nil)
>>> Constraint type check failed in binding to parameter '$in'; expected
>>> non-Nil but got Nil (Nil)
>>>   in sub in-check at  line 1
>>>   in block  at  line 1
>>>
>>> $ raku --version
>>> This is Rakudo version 2020.07 built on MoarVM version 2020.07
>>> implementing Raku 6.d.
>>>
>>> Is this my understanding of return type checking that's off, or a known
>>> issue, or something I should add to an issue tracker?
>>>
>>> -y
>>>
>>

Re: Checking for nil return

[yary]

Been thinking about this, and checked out the Rakudo repository to peek
into the source.

Allowing Failure as a return always makes sense to me– every block needs to
be capable of passing along a failure, that's how the language is designed.

On the other hand, Nil is not a Failure. Conceptually it is a lack of an
answer, similar to SQL's null concept.

What's the usefulness of having Nil skip return type checking- specifically
Nil and not its Failure descendents?

This example under https://docs.raku.org/type/Nil shows what I think is a
less-than-awesome specification, and I am curious about the reasoning
behind it being defined as valid

sub a( --> Int:D ) { return Nil }



-y


On Sun, Dec 20, 2020 at 7:18 PM Brad Gilbert  wrote:

> Nil is always a valid return value regardless of any check.
>
> This is because it is the base of all failures.
>
> On Sat, Dec 19, 2020, 8:17 PM yary  wrote:
>
>> Is this a known issue, or my misunderstanding?
>>
>> > subset non-Nil where * !=== Nil;
>> (non-Nil)
>> > sub out-check($out) returns non-Nil { return $out }
>> 
>> > out-check(44)
>> 44
>> > out-check(Nil)
>> Nil
>>
>> ^ Huh, I expected an exception on "out-check(Nil)" saying the return
>> value failed the "returns" constraint.
>>
>> The subtype works as I expect as an the argument check
>>
>> > sub in-check (non-Nil $in) { $in }
>> 
>> > in-check(33)
>> 33
>> > in-check(Nil)
>> Constraint type check failed in binding to parameter '$in'; expected
>> non-Nil but got Nil (Nil)
>>   in sub in-check at  line 1
>>   in block  at  line 1
>>
>> $ raku --version
>> This is Rakudo version 2020.07 built on MoarVM version 2020.07
>> implementing Raku 6.d.
>>
>> Is this my understanding of return type checking that's off, or a known
>> issue, or something I should add to an issue tracker?
>>
>> -y
>>
>

Re: Multiline/embedded comments

[Parrot Raiser]

> On 12/22/20, Vadim Belman  wrote:
>>
>> You interpret it incorrectly. The problem is in your '#`{' comment

On 12/23/20, Parrot Raiser <1parr...@gmail.com> wrote:
> Removing the space between the #` and { changes the error message to:
>
> ===SORRY!=== Error while compiling /home/guru/bin/comment_test
> Couldn't find terminator } (corresponding { was at line 12)
> at /home/guru/bin/comment_test:19
> --> ⏏
> expecting any of:
> }
>
> Should the parser not ignore anything between the start of the comment
> and the corresponding right-hand end, regardless of what is inside,
> whether it looks like code or not? Obviously, it has to go through the
> text to find the matching end character, but should it be looking for
> pairs inside? If it would be unreasonably difficult to change the
> mechanism, then it needs to be described.
>
> A note in the documents about the significance of whitespace after the
> backtick would be good.  I'd suggest changing the second line of the 
> definition from:

"bracketing character, and end with the matching closing bracketing
character. Only the paired "

to read:

bracketing character, and end with the matching closing bracketing
character.  Whitespace is not permitted between the backtick and the
bracketing character; it will be treated as a single-line comment.
Only the paired...

If the internal pairing is to be required, I suggest the line in the
last paragraph be changed from:

"until the very end of the string. You may also use multiple curly braces.."

to read

until the very end of the string.  If the opening bracketing character
occurs in the body of the comment, e.g. #`[ This is a box [ of stuff ]
], it must have a paired closing character, as shown. You may also use
multiple curly braces...

Re: Multiline/embedded comments

[Vadim Belman]

You interpret it incorrectly. The problem is in your '#`{' comment. You have a 
space between the backtick and the opening brace. Therefore it's interpreted as 
a single line comment. Though even if you remove the space the compiler will 
complain because it wouldn't find closing } due to unbalanced opening one at 
line 13. Note that comments treated as-is literally, backslash doesn't escape 
the brace. To get what you want you might use '#`{{ ... }}` form of 
opening/closing braces. In this case Rakudo will not try to balance the sinlge 
opening one inside the comment.

Best regards,
Vadim Belman

> On Dec 22, 2020, at 7:59 PM, Parrot Raiser <1parr...@gmail.com> wrote:
> 
> While playing around with the bounding characters for the #` form, I
> encountered an unexpected feature, which may or may not be a bug. If
> the left bounding character (e.g. the { in #`{ occurs unbalanced in
> the commented text, the compiler apparently treats it as code,
> searches for the right bounder, and generates an error if it can't
> find one. e.g.
> 
> 1 #! /home/guru/bin/raku
>  2
>  3 #  comment_test
>  4
>  5 #  Input
>  6 #  Purpose of program - test multi-line comments
>  7
>  8 #`(
>  9  put " () fails";
> 10 )
> 11
> 12 #` {
> 13  put "\{ fails";
> 14 }
> 15
> 16 put "Done";
> 17
> 18 # End comment_test Last changed: 2020-12-22 19:40:07
> 
> produces
> 
> ===SORRY!=== Error while compiling /home/guru/bin/comment_test
> Unexpected closing bracket
> at /home/guru/bin/comment_test:14
> --> ⏏}
> 
> Removing the escape \ on line 13 generates a different but related error.
> 
> Is this a limitation that should be mentioned in the description of
> the form, or the compiler mistakienly working on something it's just
> been told to ignore?
> 

Multiline/embedded comments

[Parrot Raiser]

While playing around with the bounding characters for the #` form, I
encountered an unexpected feature, which may or may not be a bug. If
the left bounding character (e.g. the { in #`{ occurs unbalanced in
the commented text, the compiler apparently treats it as code,
searches for the right bounder, and generates an error if it can't
find one. e.g.

 1 #! /home/guru/bin/raku
  2
  3 #  comment_test
  4
  5 #  Input
  6 #  Purpose of program - test multi-line comments
  7
  8 #`(
  9  put " () fails";
 10 )
 11
 12 #` {
 13  put "\{ fails";
 14 }
 15
 16 put "Done";
 17
 18 # End comment_test Last changed: 2020-12-22 19:40:07

produces

===SORRY!=== Error while compiling /home/guru/bin/comment_test
Unexpected closing bracket
at /home/guru/bin/comment_test:14
--> ⏏}

Removing the escape \ on line 13 generates a different but related error.

Is this a limitation that should be mentioned in the description of
the form, or the compiler mistakienly working on something it's just
been told to ignore?

Re: Checking for nil return

[Brad Gilbert]

Nil is always a valid return value regardless of any check.

This is because it is the base of all failures.

On Sat, Dec 19, 2020, 8:17 PM yary  wrote:

> Is this a known issue, or my misunderstanding?
>
> > subset non-Nil where * !=== Nil;
> (non-Nil)
> > sub out-check($out) returns non-Nil { return $out }
> 
> > out-check(44)
> 44
> > out-check(Nil)
> Nil
>
> ^ Huh, I expected an exception on "out-check(Nil)" saying the return value
> failed the "returns" constraint.
>
> The subtype works as I expect as an the argument check
>
> > sub in-check (non-Nil $in) { $in }
> 
> > in-check(33)
> 33
> > in-check(Nil)
> Constraint type check failed in binding to parameter '$in'; expected
> non-Nil but got Nil (Nil)
>   in sub in-check at  line 1
>   in block  at  line 1
>
> $ raku --version
> This is Rakudo version 2020.07 built on MoarVM version 2020.07
> implementing Raku 6.d.
>
> Is this my understanding of return type checking that's off, or a known
> issue, or something I should add to an issue tracker?
>
> -y
>

Re: Checking for nil return

[yary]

After writing that email, I remembered a bit of logic from a class long
ago, that any assertion made on the empty set is true. Since Nil is a
representation of no results, it would make sense to have assertions about
it return true. I think this example shows an optimization to skip return
type checking on Nil, more than a container reverting to its default value.

In particular the error message on using Nil for "in-check (non-Nil $in)"
says "expected non-Nil but got Nil (Nil)" which is preserving the Nil, it
isn't complaining about Any. And in fact "Any" passes the in-check, as I
expect it to.

I suspect that the return value assertion in the signature is a
work-in-progress– in fact part of the reason this test uses "subset
non-Nil" is that having a "where" clause in the returns signature is
explicitly a TODO:

> sub returns-prime (Int $ident --> Int where *.is-prime) { $ident }
===SORRY!=== Error while compiling:
Cannot do non-typename cases of type_constraint yet

Thus I think that handling "Nil" in the return type checking is similarly
something that is going to be fixed. Though I am still not completely sure
due to the nature of Nil being a defined type object.

-y


On Sun, Dec 20, 2020 at 2:35 PM Joseph Brenner  wrote:

> yary  wrote:
> > Is this a known issue, or my misunderstanding?
> >
> >> subset non-Nil where * !=== Nil;
> > (non-Nil)
> >> sub out-check($out) returns non-Nil { return $out }
> > 
> >> out-check(44)
> > 44
> >> out-check(Nil)
> > Nil
> >
> > ^ Huh, I expected an exception on "out-check(Nil)" saying the return
> value
> > failed the "returns" constraint.
>
> I'm seeing the same behavior that Yary does, and it does seem pretty
> peculiar.
>
> I would guess it has to do with this behavior:
>
> # https://docs.raku.org/type/Nil#index-entry-Nil_assignment
>
> # When assigned to a container, the Nil value (but not any subclass
> # of Nil) will attempt to revert the container to its default
> # value; if no such default is declared, Raku assumes Any.
>
> Something like: the Nil is getting transformed into an empty (Any),
> which passes the constraint, but then gets turned back into a Nil
> later.
>

Re: Checking for nil return

[Joseph Brenner]

yary  wrote:
> Is this a known issue, or my misunderstanding?
>
>> subset non-Nil where * !=== Nil;
> (non-Nil)
>> sub out-check($out) returns non-Nil { return $out }
> 
>> out-check(44)
> 44
>> out-check(Nil)
> Nil
>
> ^ Huh, I expected an exception on "out-check(Nil)" saying the return value
> failed the "returns" constraint.

I'm seeing the same behavior that Yary does, and it does seem pretty peculiar.

I would guess it has to do with this behavior:

# https://docs.raku.org/type/Nil#index-entry-Nil_assignment

# When assigned to a container, the Nil value (but not any subclass
# of Nil) will attempt to revert the container to its default
# value; if no such default is declared, Raku assumes Any.

Something like: the Nil is getting transformed into an empty (Any),
which passes the constraint, but then gets turned back into a Nil
later.

Checking for nil return

[yary]

Is this a known issue, or my misunderstanding?

> subset non-Nil where * !=== Nil;
(non-Nil)
> sub out-check($out) returns non-Nil { return $out }

> out-check(44)
44
> out-check(Nil)
Nil

^ Huh, I expected an exception on "out-check(Nil)" saying the return value
failed the "returns" constraint.

The subtype works as I expect as an the argument check

> sub in-check (non-Nil $in) { $in }

> in-check(33)
33
> in-check(Nil)
Constraint type check failed in binding to parameter '$in'; expected
non-Nil but got Nil (Nil)
  in sub in-check at  line 1
  in block  at  line 1

$ raku --version
This is Rakudo version 2020.07 built on MoarVM version 2020.07
implementing Raku 6.d.

Is this my understanding of return type checking that's off, or a known
issue, or something I should add to an issue tracker?

-y

[Raku/old-design-docs] 63e44c: S22: Clarify how system specific values work and c...

[niner via perl6-language]

  Branch: refs/heads/master
  Home:   https://github.com/Raku/old-design-docs
  Commit: 63e44c36351887f1eb76500d7102f0db44848d27
  
https://github.com/Raku/old-design-docs/commit/63e44c36351887f1eb76500d7102f0db44848d27
  Author: niner 
  Date:   2020-10-01 (Thu, 01 Oct 2020)

  Changed paths:
M S22-package-format.pod

  Log Message:
  ---
  S22: Clarify how system specific values work and correct the list of variables

[Raku/old-design-docs] b13e78: Update dependency specifications in S22

[niner via perl6-language]

  Branch: refs/heads/master
  Home:   https://github.com/Raku/old-design-docs
  Commit: b13e78fe5b9dc10bfdacb0122ea40a77b6037ac9
  
https://github.com/Raku/old-design-docs/commit/b13e78fe5b9dc10bfdacb0122ea40a77b6037ac9
  Author: Stefan Seifert 
  Date:   2020-09-30 (Wed, 30 Sep 2020)

  Changed paths:
M S22-package-format.pod

  Log Message:
  ---
  Update dependency specifications in S22

An attempt at implementation has shows that using lists for dependency
alternatives causes confusion and is not self-documenting enough as the depends
section itself consists of a list. Using an object with an any key is more
clear and lends itself to future expansion.

Collapsing of system specific values has always been meant to also cover
dependencies. This is now stated explicitly and the details on what's available
described.

The build-depends and test-depends keys are deprecated. They should not have
been part of the v1 META spec. Leaving them in was just an oversight.

Fwd: unflattering flat

[William Michels via perl6-language]

Migrating this question over from perl6-users  :

Can someone explain why in the second and third REPL code lines below,
line 2 returns a List while line 3 returns a Seq? And is there a
general rule to remember which code returns which data structure?

1> my %hash-with-arrays = a => [1,2], b => [2,3];
{a => [1 2], b => [2 3]}
>
2> %hash-with-arrays.values>>.map({$_}) #makes a List
((1 2) (2 3))
>
3> %hash-with-arrays.values.map({.flat}) #makes a Seq
((1 2) (2 3))
>

Thank you in advance, Bill.



-- Forwarded message -
Date: Wed, Apr 22, 2020 at 8:58 AM
Subject: Re: unflattering flat
To: perl6-users 


Regarding a recent discussion on flattening hash values. Here are some
posted answers:

>#Konrad Bucheli
> my %hash-with-arrays = a => [1,2], b => [2,3];
{a => [1 2], b => [2 3]}
> %hash-with-arrays.values>>.map({$_}) #makes a List
((1 2) (2 3))
> %hash-with-arrays.values>>.map({$_}).flat
(2 3 1 2)
>#ElizabethMattijsen
>  %hash-with-arrays.values.map( { $_.Slip } )
(1 2 2 3)
> say %hash-with-arrays.values.map: |*
(1 2 2 3)
>#Larry Wall
> %hash-with-arrays.values»[].flat
(2 3 1 2)
> say gather %hash-with-arrays.values.deepmap: { .take }
(1 2 2 3)

I played with Raku/Perl6 a bit and found two more constructs on my
own. The first one (A) with {.self} flattens the hash values as
intended.  The second one (B) produces a "Sequence of sequences",
which I don't think I've seen before:

>#Me
A> %hash-with-arrays.values.map({.self}).flat
(1 2 2 3)
>
B> %hash-with-arrays.values.map({.flat}) #makes a Seq
((1 2) (2 3))
> dd(%hash-with-arrays.values.map({.flat}))
((1, 2).Seq, (2, 3).Seq).Seq
Nil
> %hash-with-arrays.values.map({.flat}).WHAT
(Seq)
>

Question: why not a "List of sequences" instead?  Any precedent in
Perl5? What is a "Sequence of sequences" useful for (above and beyond
a "List of sequences")?  How can I predict a priori whether a
particular line of code will return a Seq or a List?

In fact, in comparison to the List generated from Konrad's code, the
auto-printed REPL ".gists" are identical between the .Seq and List
objects above, and it's only upon calling ".elems" that a user sees
that one returns 4 elements while the other returns 2 elements (which
could be confusing).

Thx, Bill.


On Mon, Apr 6, 2020 at 6:20 PM Brad Gilbert  wrote:
>
> [*] is also a meta prefix op
>
> say [*] 4, 3, 2; # 24
>
> But it also looks exactly the same as the [*] postfix combination of operators
>
> my @a = 1,2,3;
>
> say @a[*]; # (1 2 3)
>
> There is supposed to be one that looks like [**]
>
> my @b = [1,], [1,2], [1,2,3];
>
> say @b[**]; # (1 1 2 1 2 3)
>
> Really @a[*] is
>
> say postfix:« [ ] »( @a, Whatever )
>
> And @b[**] is
>
> say postfix:« [ ] »( @b, HyperWhatever )
>
> ---
>
> say *.WHAT.^name; # Whatever
>
> say **.WHAT.^name; # HyperWhatever
>
> On Mon, Apr 6, 2020 at 7:05 PM yary  wrote:
>>
>> Question- what am I missing from the below two replies?
>>
>> Larry's answer came through my browser with munged Unicode, it looks like 
>> this
>>
>>
>> - with the Chinese character for "garlic" after the word "values"
>>
>> Then Ralph says "[**] will be a wonderful thing when it's implemented" but 
>> as far as I can tell, [**] is exponentiation (math) as a hyper-op, nothing 
>> to do with flattening. From https://docs.raku.org/language/operators
>>
>> say [**] 4, 3, 2; # 4**3**2 = 4**(3**2) = 262144
>>
>>
>>

[Raku/old-design-docs]

[ven]

  Branch: refs/heads/zag-patch-1
  Home:   https://github.com/Raku/old-design-docs

[Raku/old-design-docs] 1a90f9: fix identifier in used context

[Tom Browder]

  Branch: refs/heads/master
  Home:   https://github.com/Raku/old-design-docs
  Commit: 1a90f942619e0d027f9c19228003e20a1997364d
  
https://github.com/Raku/old-design-docs/commit/1a90f942619e0d027f9c19228003e20a1997364d
  Author: Aliaksandr Zahatski 
  Date:   2020-04-26 (Sun, 26 Apr 2020)

  Changed paths:
M S26-documentation.pod

  Log Message:
  ---
  fix identifier in used context


  Commit: 93cc768ab2fe5c7440129e0e7630df3c666f6828
  
https://github.com/Raku/old-design-docs/commit/93cc768ab2fe5c7440129e0e7630df3c666f6828
  Author: Tom Browder 
  Date:   2020-04-26 (Sun, 26 Apr 2020)

  Changed paths:
M S26-documentation.pod

  Log Message:
  ---
  Merge pull request #127 from Raku/zag-patch-1

fix identifier in used context ( Synopsis 26 )


Compare: 
https://github.com/Raku/old-design-docs/compare/180b534bd6f0...93cc768ab2fe

[Raku/old-design-docs] 1a90f9: fix identifier in used context

[Aliaksandr Zahatski]

  Branch: refs/heads/zag-patch-1
  Home:   https://github.com/Raku/old-design-docs
  Commit: 1a90f942619e0d027f9c19228003e20a1997364d
  
https://github.com/Raku/old-design-docs/commit/1a90f942619e0d027f9c19228003e20a1997364d
  Author: Aliaksandr Zahatski 
  Date:   2020-04-26 (Sun, 26 Apr 2020)

  Changed paths:
M S26-documentation.pod

  Log Message:
  ---
  fix identifier in used context

[Raku/old-design-docs]

[Elizabeth Mattijsen]

  Branch: refs/heads/design-into-raku
  Home:   https://github.com/Raku/old-design-docs

[perl6/specs] 6390a5: Move the design documents into the Raku era

[Elizabeth Mattijsen]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 6390a500201b5c26512940b0920cd6e9e5111abf
  
https://github.com/perl6/specs/commit/6390a500201b5c26512940b0920cd6e9e5111abf
  Author: Elizabeth Mattijsen 
  Date:   2019-11-16 (Sat, 16 Nov 2019)

  Changed paths:
M S01-overview.pod
M S02-bits.pod
M S03-operators.pod
M S04-control.pod
M S05-regex.pod
M S06-routines.pod
M S07-lists.pod
M S08-capture.pod
M S09-data.pod
M S10-packages.pod
M S11-modules.pod
M S12-objects.pod
M S13-overloading.pod
M S14-roles-and-parametric-types.pod
M S15-unicode.pod
M S16-io.pod
M S17-concurrency.pod
M S19-commandline.pod
M S21-calling-foreign-code.pod
M S22-package-format.pod
M S24-testing.pod
M S26-documentation.pod
M S28-special-names.pod
M S29-functions.pod
M S31-pragmatic-modules.pod
M S32-setting-library/Basics.pod
M S32-setting-library/Containers.pod
M S32-setting-library/Exception.pod
M S32-setting-library/IO.pod
M S32-setting-library/Numeric.pod
M S32-setting-library/Rules.pod
M S32-setting-library/Str.pod
M S32-setting-library/Temporal.pod
M S99-glossary.pod
M html/index.html
M html/perl-with-historical-message.css
M html/style.css

  Log Message:
  ---
  Move the design documents into the Raku era

This goes beyond just replacing "Perl 6" with "Raku", and "Perl 5" by "Perl".
Clearly, many of the oldes documents still assumed that Raku was going to be
another version of "Perl", hence the word "Perl" was often used without any
digit following it.  I have tried to deduce the meaning from the context and
either changed these to "Raku" (looking towards the future), or left them to
be "Perl" (when looking to the past).

I've also done this as Raku hopefully will get some more eyeballs looking at
it, and how it got designed / conceived.  Having a mix of "Perl", "Perl 5"
and "Perl 6" in there, will only cause more confusion.  Which we do *NOT*
want to have.

Errors may have been made in this editorial process.  So please do not assume
this is canon in any way!  If you think something is wrong, let us know or
even better, provide a Pull Request!

Thank you for reading this!

[perl6/specs] 3d62b9: Move the design documents into the Raku era

[Elizabeth Mattijsen]

  Branch: refs/heads/design-into-raku
  Home:   https://github.com/perl6/specs
  Commit: 3d62b9ea86f586612d5df9ea9460a12239b6ccf2
  
https://github.com/perl6/specs/commit/3d62b9ea86f586612d5df9ea9460a12239b6ccf2
  Author: Elizabeth Mattijsen 
  Date:   2019-11-16 (Sat, 16 Nov 2019)

  Changed paths:
M S01-overview.pod
M S02-bits.pod
M S03-operators.pod
M S04-control.pod
M S05-regex.pod
M S06-routines.pod
M S07-lists.pod
M S08-capture.pod
M S09-data.pod
M S10-packages.pod
M S11-modules.pod
M S12-objects.pod
M S13-overloading.pod
M S14-roles-and-parametric-types.pod
M S15-unicode.pod
M S16-io.pod
M S17-concurrency.pod
M S19-commandline.pod
M S21-calling-foreign-code.pod
M S22-package-format.pod
M S24-testing.pod
M S26-documentation.pod
M S28-special-names.pod
M S29-functions.pod
M S31-pragmatic-modules.pod
M S32-setting-library/Basics.pod
M S32-setting-library/Containers.pod
M S32-setting-library/Exception.pod
M S32-setting-library/IO.pod
M S32-setting-library/Numeric.pod
M S32-setting-library/Rules.pod
M S32-setting-library/Str.pod
M S32-setting-library/Temporal.pod
M S99-glossary.pod
M html/index.html
M html/perl-with-historical-message.css
M html/style.css

  Log Message:
  ---
  Move the design documents into the Raku era

This goes beyond just replacing "Perl 6" with "Raku", and "Perl 5" by "Perl".
Clearly, many of the oldes documents still assumed that Raku was going to be
another version of "Perl", hence the word "Perl" was often used without any
digit following it.  I have tried to deduce the meaning from the context and
either changed these to "Raku" (looking towards the future), or left them to
be "Perl" (when looking to the past).

I've also done this as Raku hopefully will get some more eyeballs looking at
it, and how it got designed / conceived.  Having a mix of "Perl", "Perl 5"
and "Perl 6" in there, will only cause more confusion.  Which we do *NOT*
want to have.

Errors may have been made in this editorial process.  So please do not assume
this is canon in any way!  If you think something is wrong, let us know or
even better, provide a Pull Request!

Thank you for reading this!

[perl6/specs] 180b53: Revert "Move the design documents into the Raku era"

[Elizabeth Mattijsen]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 180b534bd6f012e7576384326f2e915162c496be
  
https://github.com/perl6/specs/commit/180b534bd6f012e7576384326f2e915162c496be
  Author: Elizabeth Mattijsen 
  Date:   2019-11-16 (Sat, 16 Nov 2019)

  Changed paths:
M S01-overview.pod
M S02-bits.pod
M S03-operators.pod
M S04-control.pod
M S05-regex.pod
M S06-routines.pod
M S07-lists.pod
M S08-capture.pod
M S09-data.pod
M S10-packages.pod
M S11-modules.pod
M S12-objects.pod
M S13-overloading.pod
M S14-roles-and-parametric-types.pod
M S15-unicode.pod
M S16-io.pod
M S17-concurrency.pod
M S19-commandline.pod
M S21-calling-foreign-code.pod
M S22-package-format.pod
M S24-testing.pod
M S26-documentation.pod
M S28-special-names.pod
M S29-functions.pod
M S31-pragmatic-modules.pod
M S32-setting-library/Basics.pod
M S32-setting-library/Containers.pod
M S32-setting-library/Exception.pod
M S32-setting-library/IO.pod
M S32-setting-library/Numeric.pod
M S32-setting-library/Rules.pod
M S32-setting-library/Str.pod
M S32-setting-library/Temporal.pod
M S99-glossary.pod
M html/index.html
M html/perl-with-historical-message.css
M html/style.css

  Log Message:
  ---
  Revert "Move the design documents into the Raku era"

This reverts commit 6390a500201b5c26512940b0920cd6e9e5111abf.

Will re-commit as a PR

[perl6/specs] c5aa24: Remove obsolete file

[Elizabeth Mattijsen]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: c5aa24071599a46240ba09cd9c91a37749799d7e
  
https://github.com/perl6/specs/commit/c5aa24071599a46240ba09cd9c91a37749799d7e
  Author: Elizabeth Mattijsen 
  Date:   2019-11-16 (Sat, 16 Nov 2019)

  Changed paths:
R S22-package-format-OLD.pod

  Log Message:
  ---
  Remove obsolete file

[perl6/specs] 4508e5: correct spelling for "resources" as in current usage

[Tom Browder]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 4508e535661ccd1366e492960d54aab97be87bbe
  
https://github.com/perl6/specs/commit/4508e535661ccd1366e492960d54aab97be87bbe
  Author: Tom Browder 
  Date:   2019-10-02 (Wed, 02 Oct 2019)

  Changed paths:
M S22-package-format.pod

  Log Message:
  ---
  correct spelling for "resources" as in current usage

Also makes the usage consistent with the other, already existing, uses in the 
file.

Rakudo update due?

[Parrot Raiser]

The current version of Rakudo* is 2019.03, which makes it 5 months old.
Is there likely to be an update soon? (The underlying compiler seems
to have had a few fixes.)
 (No pressure, I just want to stay as up-to-date as possible.)

Re: Diagnostics?

[Vadim Belman]

If you think this is a bug you're always welcome to open a ticket at 
https://github.com/rakudo/rakudo/issues. Even if it eventually would turn out 
to be not a bug that wouldn't hurt anybody.

In either case it would be very welcomed to always include examples paired with 
output.

Best regards,
Vadim Belman

> On Jul 8, 2019, at 11:42 AM, Parrot Raiser <1parr...@gmail.com> wrote:
> 
> I've been fiddling with multi-line comments and the bounding
> characters. Naturally-paired characters  e.g. #`(...)  #`[...] #`{...}
> all work well, but with other boundary characters like #`@@ or
> #`!! produce odd, displaced, diagnostic messages. Reproducing them
> is so easy, I'll leave it as "an exercise for the reader".
> 
> If unpaired boundary characters like these are legal, presumably
> there's a problem with the parser or compiler?
> If they aren't, maybe a) the docs should be more explicit, and b), the
> diagnostics should say so, immediately?
> 
> perl6 -v
> This is Rakudo Star version 2019.03.1 built on MoarVM version 2019.03
> 

Diagnostics?

[Parrot Raiser]

I've been fiddling with multi-line comments and the bounding
characters. Naturally-paired characters  e.g. #`(...)  #`[...] #`{...}
all work well, but with other boundary characters like #`@@ or
#`!! produce odd, displaced, diagnostic messages. Reproducing them
is so easy, I'll leave it as "an exercise for the reader".

If unpaired boundary characters like these are legal, presumably
there's a problem with the parser or compiler?
If they aren't, maybe a) the docs should be more explicit, and b), the
diagnostics should say so, immediately?

perl6 -v
This is Rakudo Star version 2019.03.1 built on MoarVM version 2019.03

Re: Announce: french perl workshop (Aka Journées Perl)

[Laurent Rosenfeld via perl6-language]

Hello Mark,

I was thinking about submitting a talk on the P6 Object System, but I could
also change it to Grammars (or do both).

Cheers,
Laurent.


Le mar. 21 mai 2019 à 10:30, Marc Chantreux  a écrit :

> hello perl6 people,
>
> we hope there will be some events around the French Perl Worshop
> (aka journées perl)
>
> https://journeesperl.fr/jp2019/
>
> there will be at least a "perl6 modules hackathon" (trying to contribute
> to the perl6 ecosystem). however i really would like to see a talk or a
> workshop about perl6. some ideas of topics that can be appreciated by
> the audience as well as trivial for some of you:
>
> * perl6 module path (and bytecoded version)
> * getting started with
> * zef and mi6
> * Cro
> * NativeCall
> * Grammars
>
> so we'll be pleased to see you all and if you think you can give a talk:
> don't be shy and show us your perl6 :)
>
> regards
> marc
>

EnumStr necessary for MAIN handling (was Fwd: [rakudo/rakudo] `MAIN`: `Str` arguments do not accept `True` or `False` (#2794))

[Trey Ethan Harris]

If one uses MAIN with arguments, one simply cannot get strings like
"Bool::True" and "True" from the command line into the same argument,
regardless of whether one uses no type constraint, a Str, a Str(), or a
slurpy. See the quote below from rakudo #2794
 for an example.

I think a built-in EnumStr Perl 6 type is necessary to fix this—though it's
arguable that since CLI's are, for the most part, string-native, an
argument type-constrained to Str on MAIN should get absolutely anything the
shell hands it untouched.

Are there any other candidate types MAIN's parser reads that don't have
allomorphic counterparts, or will EnumStr fix the issue entirely?

Trey

-- Forwarded message -
From: Trey Harris 
Date: Mon, Mar 25, 2019 at 14:38
Subject: Re: [rakudo/rakudo] `MAIN`: `Str` arguments do not accept `True`
or `False` (#2794)
To: rakudo/rakudo 

I think an 'EnumStr' is a requirement, actually, after considering this
example:

% ./cat-p6 *@*ARGS is ["cat-p6"]=== cat-p6 ===#!/usr/bin/env perl6
unit sub MAIN(*@files);
say '@*ARGS is ', @*ARGS.perl;
for @files -> $f {  say "=== $f ===";  put $f.IO.lines.join("\n");}
% for file in 42 hi True Bool::True; dofor> echo "This is $file" >
$filefor> done
% ls42  Bool::True  True  cat-p6  hi
% ./cat-p6 *@*ARGS is ["42", "Bool::True", "True", "cat-p6", "hi"]===
42 ===This is 42=== True ===This is True=== True ===This is True===
cat-p6 ===#!/usr/bin/env perl6
unit sub MAIN(*@files);
say '@*ARGS is ', @*ARGS.perl;
for @files -> $f {  say "=== $f ===";  put $f.IO.lines.join("\n");}===
hi ===This is hi

Without taking over @*ARG handling, it's impossible to access the file
named "Bool::True". That can't be right.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
, or mute
the thread

.

[perl6/specs] e5b176: Fix typo

[Carl Mäsak]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: e5b176cae67ba74035dd2be3518dca863f5e780e
  
https://github.com/perl6/specs/commit/e5b176cae67ba74035dd2be3518dca863f5e780e
  Author: Carl Masak 
  Date:   2019-02-09 (Sat, 09 Feb 2019)

  Changed paths:
M S03-operators.pod

  Log Message:
  ---
  Fix typo

Submethods in roles

[Vadim Belman]

Hello,

I'm working on a fix for https://github.com/rakudo/rakudo/issues/2250. While 
the problem itself is easily tracks down to add_method not reporting a error, 
the general fix requires clear understanding of what happens to submethods when 
a role consumes another role. While things are pretty straightforward for 
methods, which are copied over from the source role to the target, for 
submethods not everything is so clear as I see it. Let's consider the following 
setup:

role R1 { submethod foo { "R1::foo" } }
role R2 does R1 { }
class Foo does R2 { submethod foo { "Foo::foo" } }

Imagine a code which would like to execute all submethods of all classes and 
roles. Normally, it would traverse mro and all role concretizations of each 
class from mro. In the example above such code would call submethod foo() from 
R1 twice: for R2 and R1 itself! Of course, there is a workaround for this as 
foo from R1 will have its .package set to R1. But what sense does such copying 
makes? When a role gets applied to class it does make some sense when we talk 
about BUILD/TWEAK/DESTROY. Though if 
https://github.com/rakudo/rakudo/issues/2241 gets implemented then even this 
use case will be obsoleted.

So, to have a comprehensive fix for #2250 I need to know how to handle 
submethods when a role is applied to a role: either I leave them untouched 
where they're (and this would be my choice); or I get them copied alongside 
with methods.

Best regards,
Vadim Belman

If anyone has a use for "perl6-contrib" on Github...

[Trey Ethan Harris]

This came up yesterday and I wanted to capture it:

I've been sitting on the name just in case (I grabbed it when it briefly
seemed like we needed an "in-between" place for non-core, non-ecosystem
stuff like editor-support packages).

Right now, https://github.com/perl6-contrib is just sitting there with me
as the only member and nothing else (though I did freehand sketch a Camelia
profile image with "P6 CO", just for fun).

Anyway, it's there if the need arises; just let me know.

Trey

Announce: Rakudo Star Release 2018.10

[Steve Mynott]

Announce: Rakudo Star Release 2018.10 A useful and usable production
distribution of Rakudo Perl 6

On behalf of the Rakudo and Perl 6 development teams, I'm pleased to
announce the October 2018 release of "Rakudo Star", a useful and usable
production distribution of Rakudo. The tarball for this release is
available from https://rakudo.perl6.org/downloads/star/.

Binaries for macOS and Windows (64 bit) are also available at the same
location.

This is a post-Christmas (production) release of Rakudo Star and implements
Perl v6.c. It comes with support for the MoarVM backend (all module tests
pass on supported platforms). Currently, Star is on a quarterly release
cycle.

Please note that this release of Rakudo Star is not fully functional with
the JVM backend from the Rakudo compiler. Please use the MoarVM backend
only.

We make a distinction between the language ("Perl 6" or "Raku") and
specific implementations of the language such as "Rakudo".

This Star release includes release 2018.10

of the Rakudo compiler , version 2018.10
MoarVM , plus various modules, documentation, and other
resources collected from the community.

The Rakudo compiler changes since the last Rakudo Star release are now
listed in "2018.08.md" and 2018.09.md" under the "rakudo/docs/announce"
directory of the source distribution.

This is the first Rakudo Star release that comes with an additional JS
backend. See 6pad project at https://perl6.github.io/6pad/ for running
Perl 6 code directly in your browser.

Important Rakudo bug fixes are now listed at https://alerts.perl6.org/

Also see Rakudo Star errata at https://perl6.org/downloads/

Deprecation:

   - LWP::Simple is deprecated and will be removed. Please use
   "HTTP::UserAgent".
   - panda-sub which pointed user to zef now removed.

Notable changes in modules shipped with Rakudo Star:

   - openssl: Bump version 0.1.21.
   - tap-harness6: Bump version to 0.0.4 for coloring
   - zef: version 0.5.3

There are some key features of Perl 6 that Rakudo Star does not yet handle
appropriately, although they will appear in upcoming releases. Some of the
not-quite-there features include:

   - advanced macros
   - some bits of Synopsis 9 and 11

There is an online resource at http://perl6.org/compilers/features that
lists the known implemented and missing features of Rakudo's backends and
other Perl 6 implementations.

In many places we've tried to make Rakudo smart enough to inform the
programmer that a given feature isn't implemented, but there are many that
we've missed. Bug reports about missing and broken features are welcomed at
rakudo...@perl.org.

See https://perl6.org/ for links to much more information, including
documentation, example code, tutorials, presentations, reference materials,
design documents, and other supporting resources. Tutorials are available
under the "docs" directory in the release tarball.

The development team thanks all of the contributors and sponsors for making
Rakudo Star possible. If you would like to contribute, see
http://rakudo.org/how-to-help, ask on the perl6-compi...@perl.org mailing
list, or join us on IRC #perl6 on freenode.

-- 
Steve Mynott 
cv25519/ECF8B611205B447E091246AF959E3D6197190DD5

[perl6/specs] f42464: Update email address

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: f424643a5bd6ac3e3879b89c33c5b266f009dba7
  
https://github.com/perl6/specs/commit/f424643a5bd6ac3e3879b89c33c5b266f009dba7
  Author: Elizabeth Mattijsen 
  Date:   2018-10-29 (Mon, 29 Oct 2018)

  Changed paths:
M S03-operators.pod
M S11-modules.pod
M S16-io.pod
M S17-concurrency.pod
M S22-package-format.pod
M S24-testing.pod
M S29-functions.pod
M S32-setting-library/IO.pod
M S99-glossary.pod

  Log Message:
  ---
  Update email address



  **NOTE:** This service has been marked for deprecation: 
https://developer.github.com/changes/2018-04-25-github-services-deprecation/

  Functionality will be removed from GitHub.com on January 31st, 2019.

Re: $? and $! equivalents

[N6Ghost]

On Fri, 14 Sep 2018 18:15:21 -0400
Brandon Allbery  wrote:

> Magic variables make multiple threads impossible, which is why perl 5
> is stuck with ithreads: what happens if two threads each "run"
> something at around the same time?
> 
> In Perl 6, you have a Proc object for each subprocess, and can query
> it for its status and/or result code; for things like sub run, the
> Proc should be the return value.
> 
> On Fri, Sep 14, 2018 at 6:08 PM Parrot Raiser <1parr...@gmail.com>
> wrote:
> 
> > This is probably going to be a forehead-slapper, but I can't find a
> > reference in either perlintro.com or http://docs.perl6.org/
> > (5to6-perlfunc or top-down)  for the equivalents of $? and $! in
> > P6.What are they?
> >
> > I want to be able to "run" or "shell" programs, then examine return
> > codes and errors. (The immediate case is to see if a program name is
> > already in use by running  "which $progname". )
> >  
> 
> 

this is very good to know. 

Re: "put" vs "say"

[Parrot Raiser]

Thanks for the suggestions. I ran a couple of tests:

my $data_list = 1..1001;
say $data_list;

produces
1..1000

real0m0.357s
user0m0.435s
sys 0m0.048s

my $data_list = 1..1001;
put $data_list;

produces the list of integers from 1 to 1001 (obviously a single string).


real0m0.470s
user0m0.452s
sys 0m0.058s

Changing the list to an array,

say produces
[1 2 3 4 5 6 () 98 99 100 ...]

real0m0.435s
user0m0.484s
sys 0m0.056s

put result is unchanged in

real0m0.424s
user0m0.445s
sys 0m0.068s

Further research is clearly required, as all good research reports say.

On 10/21/18, Timo Paulssen  wrote:
> put is meant for machines, while say is meant for humans.
>
> this is implemented by having say call the .gist method and put calling
> the .Str method.
>
> Try using say and put on a list of a thousand elements or more and
> you'll see what I mean.
>
> HTH
>   - Timo
>
> On 21/10/2018 18:29, Parrot Raiser wrote:
>> "put" and "say" seem to be redundant, but I'm sure there's a good
>> reason for having 2 output commands.
>>
>> Would anyone care to comment on how they differ and why, or point to
>> an explanation?
>

Re: "put" vs "say"

[Timo Paulssen]

put is meant for machines, while say is meant for humans.

this is implemented by having say call the .gist method and put calling
the .Str method.

Try using say and put on a list of a thousand elements or more and
you'll see what I mean.

HTH
  - Timo

On 21/10/2018 18:29, Parrot Raiser wrote:
> "put" and "say" seem to be redundant, but I'm sure there's a good
> reason for having 2 output commands.
>
> Would anyone care to comment on how they differ and why, or point to
> an explanation?

"put" vs "say"

[Parrot Raiser]

"put" and "say" seem to be redundant, but I'm sure there's a good
reason for having 2 output commands.

Would anyone care to comment on how they differ and why, or point to
an explanation?

Re: "temp" vs "my"

[Jonathan Scott Duff]

What you want is OUTER ...

my $v  = "original";
> {
> my $v = OUTER::<$v>;
> say $v;
> $v = "new one";
> say $v;
> }
> say $v;



It's how you access the outer scope from an inner scope.

-Scott

On Wed, Oct 3, 2018 at 1:10 AM yary  wrote:

> Reading and playing with https://docs.perl6.org/routine/temp
>
> There's an example showing how temp is "dynamic" - that any jump outside a
> block restores the value. All well and good.
>
> Then I thought, what if I want a lexical temporary value- then use "my"-
> and this is all well and good:
>
> my $v = "original";
> {
> my $v = "new one";
> start {
> say "[PROMISE] Value before block is left: `$v`";
> sleep 1;
> say "[PROMISE] Block was left while we slept; value is still `$v`";
> }
> sleep ½;
> say "About to leave the block; value is `$v`";
> }
> say "Left the block; value is now `$v`";
> sleep 2;
>
> Then I thought, well, what if I want to initialize the inner $v with the
> outer $v.
>
> my $v = "original";
> {
> my $v = $v; # "SORRY! Cannot use variable $v in declaration to
> initialize itself"
> say "inner value is $v";
> $v= "new one";
> ...
>
> Gentle reader, how would you succinctly solve this contrived example?
> Anything you like better than this?
>
> my $v = "original";
> given $v -> $v is copy {
> say "inner value is $v"; # "original", good
> $v= "new one";
> 
>
> -y
>

Re: "temp" vs "my"

[Brad Gilbert]

Note that OUTER::<$v> only goes up one level.

So to go up two levels OUTER::OUTER::<$v>

There is also OUTERS::<$v> which will go up as many levels as it needs
to find the variable

{
   my $a = 1;
   my $b = 2;
   {
   my $a = 3;
   {
   say OUTER::<$a>; # 3
   say OUTER::OUTER::<$a>; # 1

   say OUTERS::<$a>; # 3  # only one level
   say OUTERS::<$b>; # 2  # two levels
   }
   }
}
On Wed, Oct 3, 2018 at 10:31 AM yary  wrote:
>
> Thanks! Knew I'd seen the concept of OUTER but couldn't remember the keyword.
>
> -y
>
> On Wed, Oct 3, 2018 at 5:51 AM, Timo Paulssen  wrote:
>>
>> you can refer to the outer $v as OUTER::('$v'), that ought to help :)
>>
>> On 03/10/2018 08:10, yary wrote:
>>
>> Reading and playing with https://docs.perl6.org/routine/temp
>>
>> There's an example showing how temp is "dynamic" - that any jump outside a 
>> block restores the value. All well and good.
>>
>> Then I thought, what if I want a lexical temporary value- then use "my"- and 
>> this is all well and good:
>>
>> my $v = "original";
>> {
>> my $v = "new one";
>> start {
>> say "[PROMISE] Value before block is left: `$v`";
>> sleep 1;
>> say "[PROMISE] Block was left while we slept; value is still `$v`";
>> }
>> sleep ½;
>> say "About to leave the block; value is `$v`";
>> }
>> say "Left the block; value is now `$v`";
>> sleep 2;
>>
>> Then I thought, well, what if I want to initialize the inner $v with the 
>> outer $v.
>>
>> my $v = "original";
>> {
>> my $v = $v; # "SORRY! Cannot use variable $v in declaration to 
>> initialize itself"
>> say "inner value is $v";
>> $v= "new one";
>> ...
>>
>> Gentle reader, how would you succinctly solve this contrived example? 
>> Anything you like better than this?
>>
>> my $v = "original";
>> given $v -> $v is copy {
>> say "inner value is $v"; # "original", good
>> $v= "new one";
>> 
>>
>> -y
>
>

Re: "temp" vs "my"

[yary]

Thanks! Knew I'd seen the concept of OUTER but couldn't remember the
keyword.

-y

On Wed, Oct 3, 2018 at 5:51 AM, Timo Paulssen  wrote:

> you can refer to the outer $v as OUTER::('$v'), that ought to help :)
> On 03/10/2018 08:10, yary wrote:
>
> Reading and playing with https://docs.perl6.org/routine/temp
>
> There's an example showing how temp is "dynamic" - that any jump outside a
> block restores the value. All well and good.
>
> Then I thought, what if I want a lexical temporary value- then use "my"-
> and this is all well and good:
>
> my $v = "original";
> {
> my $v = "new one";
> start {
> say "[PROMISE] Value before block is left: `$v`";
> sleep 1;
> say "[PROMISE] Block was left while we slept; value is still `$v`";
> }
> sleep ½;
> say "About to leave the block; value is `$v`";
> }
> say "Left the block; value is now `$v`";
> sleep 2;
>
> Then I thought, well, what if I want to initialize the inner $v with the
> outer $v.
>
> my $v = "original";
> {
> my $v = $v; # "SORRY! Cannot use variable $v in declaration to
> initialize itself"
> say "inner value is $v";
> $v= "new one";
> ...
>
> Gentle reader, how would you succinctly solve this contrived example?
> Anything you like better than this?
>
> my $v = "original";
> given $v -> $v is copy {
> say "inner value is $v"; # "original", good
> $v= "new one";
> 
>
> -y
>
>

Re: "temp" vs "my"

[Timo Paulssen]

you can refer to the outer $v as OUTER::('$v'), that ought to help :)

On 03/10/2018 08:10, yary wrote:
> Reading and playing with https://docs.perl6.org/routine/temp
>
> There's an example showing how temp is "dynamic" - that any jump
> outside a block restores the value. All well and good.
>
> Then I thought, what if I want a lexical temporary value- then use
> "my"- and this is all well and good:
>
> my $v = "original";
> {
>     my $v = "new one";
>     start {
>         say "[PROMISE] Value before block is left: `$v`";
>         sleep 1;
>         say "[PROMISE] Block was left while we slept; value is still
> `$v`";
>     }
>     sleep ½;
>     say "About to leave the block; value is `$v`";
> }
> say "Left the block; value is now `$v`";
> sleep 2;
>
> Then I thought, well, what if I want to initialize the inner $v with
> the outer $v.
>
> my $v = "original";
> {
>     my $v = $v; # "SORRY! Cannot use variable $v in declaration to
> initialize itself"
>     say "inner value is $v";
>     $v= "new one";
> ...
>
> Gentle reader, how would you succinctly solve this contrived example?
> Anything you like better than this?
>
> my $v = "original";
> given $v -> $v is copy {
>     say "inner value is $v"; # "original", good
>     $v= "new one";
> 
>
> -y

"temp" vs "my"

[yary]

Reading and playing with https://docs.perl6.org/routine/temp

There's an example showing how temp is "dynamic" - that any jump outside a
block restores the value. All well and good.

Then I thought, what if I want a lexical temporary value- then use "my"-
and this is all well and good:

my $v = "original";
{
my $v = "new one";
start {
say "[PROMISE] Value before block is left: `$v`";
sleep 1;
say "[PROMISE] Block was left while we slept; value is still `$v`";
}
sleep ½;
say "About to leave the block; value is `$v`";
}
say "Left the block; value is now `$v`";
sleep 2;

Then I thought, well, what if I want to initialize the inner $v with the
outer $v.

my $v = "original";
{
my $v = $v; # "SORRY! Cannot use variable $v in declaration to
initialize itself"
say "inner value is $v";
$v= "new one";
...

Gentle reader, how would you succinctly solve this contrived example?
Anything you like better than this?

my $v = "original";
given $v -> $v is copy {
say "inner value is $v"; # "original", good
$v= "new one";


-y

Re: $? and $! equivalents

[Parrot Raiser]

OK, different paradigm, different methods.

Thanks.

Another couple of entries for the "differences" list? Even a note the
thing doesn't exist saves fruitless further searching.

On 9/14/18, Brad Gilbert  wrote:
> On Fri, Sep 14, 2018 at 5:08 PM Parrot Raiser <1parr...@gmail.com> wrote:
>>
>> This is probably going to be a forehead-slapper, but I can't find a
>> reference in either perlintro.com or http://docs.perl6.org/
>> (5to6-perlfunc or top-down)  for the equivalents of $? and $! in
>> P6.What are they?
>>
>> I want to be able to "run" or "shell" programs, then examine return
>> codes and errors. (The immediate case is to see if a program name is
>> already in use by running  "which $progname". )
>
>my $proc = run , :out, :!in;
>say $proc.out.slurp;
>say $proc.exitcode;
>

Re: $? and $! equivalents

[Brad Gilbert]

On Fri, Sep 14, 2018 at 5:08 PM Parrot Raiser <1parr...@gmail.com> wrote:
>
> This is probably going to be a forehead-slapper, but I can't find a
> reference in either perlintro.com or http://docs.perl6.org/
> (5to6-perlfunc or top-down)  for the equivalents of $? and $! in
> P6.What are they?
>
> I want to be able to "run" or "shell" programs, then examine return
> codes and errors. (The immediate case is to see if a program name is
> already in use by running  "which $progname". )

   my $proc = run , :out, :!in;
   say $proc.out.slurp;
   say $proc.exitcode;

Re: $? and $! equivalents

[Brandon Allbery]

Magic variables make multiple threads impossible, which is why perl 5 is
stuck with ithreads: what happens if two threads each "run" something at
around the same time?

In Perl 6, you have a Proc object for each subprocess, and can query it for
its status and/or result code; for things like sub run, the Proc should be
the return value.

On Fri, Sep 14, 2018 at 6:08 PM Parrot Raiser <1parr...@gmail.com> wrote:

> This is probably going to be a forehead-slapper, but I can't find a
> reference in either perlintro.com or http://docs.perl6.org/
> (5to6-perlfunc or top-down)  for the equivalents of $? and $! in
> P6.What are they?
>
> I want to be able to "run" or "shell" programs, then examine return
> codes and errors. (The immediate case is to see if a program name is
> already in use by running  "which $progname". )
>


-- 
brandon s allbery kf8nh
allber...@gmail.com

$? and $! equivalents

[Parrot Raiser]

This is probably going to be a forehead-slapper, but I can't find a
reference in either perlintro.com or http://docs.perl6.org/
(5to6-perlfunc or top-down)  for the equivalents of $? and $! in
P6.What are they?

I want to be able to "run" or "shell" programs, then examine return
codes and errors. (The immediate case is to see if a program name is
already in use by running  "which $progname". )

Re: 3 kinds of yadda

[Trey Harris]

When executed:

   - ??? is warn.- ... is fail.
   - !!! is ‘die`.

Otherwise, they’re identical (notably, when *not* executed, which is the
usual case). You’d use ??? when you’re not implementing something yet but
it needs to be callable (say, a debugging function).

Given the difference in behavior between fail and die (fail is an unthrown
exception which is suppressed unless called in Sink context or used in an
expression as anything but a Failure or to test truth or definedness), I’d
suggest that !!! be used in a block that’s being used for its return value
(unless “always false and undefined” is an acceptable return value until
you get around to implementing it and you want to be able to call it in the
meantime), and ... elsewhere.

sub warner() { ??? }

my $x = warner(); # "Stub code executed" warning here
say "Hi!"; # Hi! is printed.

vs.

sub failer() { ... }

my $x = failer(); # nothing happens yet
say "Hi!"; # Hi! will be printed
say $x; # "Stub code executed" will be thrown here.

vs.

sub dier() { !!! }

my $x = dier(); # code will stop execution here with a "Stub code
executed" exception
say "Hi!"; # never gets here

​

On Mon, Sep 10, 2018 at 4:22 PM yary  wrote:

> Semantically
>  !!! is "if control flow hits here, it's an error"
>  ... is "The implementation is elsewhere, or this is not yet implemented"
>
> at least that's my impression
>
> -y
>
> On Mon, Sep 10, 2018 at 12:04 PM, Parrot Raiser <1parr...@gmail.com>
> wrote:
>
>> There are 3 kinds of yadda, yadda operator:
>>
>> !!! dies with a message: Stub code executed
>>   in block  at yad1 line 2
>>
>> ... dies with an identical message
>>
>> ??? produces the message, but continues operating.
>>
>> The only difference I can find between !!! and ... is that !!!
>> produces bizarre behaviour  when run from the command line. (Bash
>> appears to be editing the code before P6 sees it.)
>>
>> What is supposed to be the difference between !!! and ...? (And bonus
>> points if you can explain what bash is doing.)
>>
>
>

Re: 3 kinds of yadda

[yary]

Semantically
 !!! is "if control flow hits here, it's an error"
 ... is "The implementation is elsewhere, or this is not yet implemented"

at least that's my impression

-y

On Mon, Sep 10, 2018 at 12:04 PM, Parrot Raiser <1parr...@gmail.com> wrote:

> There are 3 kinds of yadda, yadda operator:
>
> !!! dies with a message: Stub code executed
>   in block  at yad1 line 2
>
> ... dies with an identical message
>
> ??? produces the message, but continues operating.
>
> The only difference I can find between !!! and ... is that !!!
> produces bizarre behaviour  when run from the command line. (Bash
> appears to be editing the code before P6 sees it.)
>
> What is supposed to be the difference between !!! and ...? (And bonus
> points if you can explain what bash is doing.)
>

Re: 3 kinds of yadda

[Parrot Raiser]

> Bash is treating ! as the history substitution character, and either erroring 
> out or substituting a previous command line.

Thanks; that struck me between the time I hit send and got confirmation. :-)*

3 kinds of yadda

[Parrot Raiser]

There are 3 kinds of yadda, yadda operator:

!!! dies with a message: Stub code executed
  in block  at yad1 line 2

... dies with an identical message

??? produces the message, but continues operating.

The only difference I can find between !!! and ... is that !!!
produces bizarre behaviour  when run from the command line.
(Bash appears to be interpreting !! as "rerun the previous command",
even when quoted.)

What is supposed to be the difference between !!! and ...?

Re: 3 kinds of yadda

[Brandon Allbery]

Bash is treating ! as the history substitution character, and either
erroring out or substituting a previous command line. ^ has related
behavior at the start of a line.

... is specially recognized by the compiler, for example treating a class
stubbed with ... as a forward declaration. I don't know if !!! is similar.

On Mon, Sep 10, 2018 at 3:05 PM Parrot Raiser <1parr...@gmail.com> wrote:

> There are 3 kinds of yadda, yadda operator:
>
> !!! dies with a message: Stub code executed
>   in block  at yad1 line 2
>
> ... dies with an identical message
>
> ??? produces the message, but continues operating.
>
> The only difference I can find between !!! and ... is that !!!
> produces bizarre behaviour  when run from the command line. (Bash
> appears to be editing the code before P6 sees it.)
>
> What is supposed to be the difference between !!! and ...? (And bonus
> points if you can explain what bash is doing.)
>


-- 
brandon s allbery kf8nh
allber...@gmail.com

3 kinds of yadda

[Parrot Raiser]

There are 3 kinds of yadda, yadda operator:

!!! dies with a message: Stub code executed
  in block  at yad1 line 2

... dies with an identical message

??? produces the message, but continues operating.

The only difference I can find between !!! and ... is that !!!
produces bizarre behaviour  when run from the command line. (Bash
appears to be editing the code before P6 sees it.)

What is supposed to be the difference between !!! and ...? (And bonus
points if you can explain what bash is doing.)

Reading documentaion offline?

[Parrot Raiser]

What's the simplest way of downloading current language documentation
for reading offline?

Best practices?

[Parrot Raiser]

What would be the criteria for deciding whether to name P6 constants
using  lower-case or UPPER_CASE names?

Generally,  system constants and variables use upper-case, so
lower-case keeps user variables in a separate name space. Do
user-defined constants belong there, or in upper-case to indicate that
they are global?

Apologies in advance if this starts a vicious ideological conflict.

[perl6/specs] 26266b: Update builder example to use full namespace

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 26266b1bc69cd15b58ab03338af7f3938052b666
  
https://github.com/perl6/specs/commit/26266b1bc69cd15b58ab03338af7f3938052b666
  Author: Nick Logan 
  Date:   2018-08-11 (Sat, 11 Aug 2018)

  Changed paths:
M S22-package-format.pod

  Log Message:
  ---
  Update builder example to use full namespace



  **NOTE:** This service has been marked for deprecation: 
https://developer.github.com/changes/2018-04-25-github-services-deprecation/

  Functionality will be removed from GitHub.com on January 31st, 2019.

Announce: Rakudo Star Release 2018.06

[Steve Mynott]

On behalf of the Rakudo and Perl 6 development teams, I'm pleased to announce
the June 2018 release of "Rakudo Star", a useful and usable production
distribution of Rakudo Perl 6.  The tarball for this release is available from
.

Binaries for macOS and Windows (64 bit) are also available at the same
location.

This is a post-Christmas (production) release of Rakudo Star and implements
Perl v6.c. It comes with support for the MoarVM backend (all module tests pass
on supported platforms).  Currently, Star is on a quarterly release cycle.

Please note that this release of Rakudo Star is not fully functional with the
JVM backend from the Rakudo compiler. Please use the MoarVM backend only.

In the Perl 6 world, we make a distinction between the language ("Perl 6") and
specific implementations of the language such as "Rakudo Perl 6".

This Star release includes [release 2018.06] of the [Rakudo Perl 6 compiler],
version 2018.06 [MoarVM], plus various modules, documentation, and other
resources collected from the Perl 6 community.

[release 2018.06]:
https://raw.githubusercontent.com/rakudo/rakudo/2018.06/docs/announce/2018.06.md
[Rakudo Perl 6 compiler]: http://github.com/rakudo/rakudo
[MoarVM]: http://moarvm.org/

The Rakudo compiler changes since the last Rakudo Star release are now listed
in "2018.05.md" and 2018.06.md" under the "rakudo/docs/announce" directory of
the source distribution.

Important Rakudo bug fixes are now listed at 

Also see Rakudo Star errata at 

Deprecation:

  * LWP::Simple is deprecated and will be removed. Please use "HTTP::UserAgent".

Notable changes in modules shipped with Rakudo Star:

  * openssl: added
  * io-socket-ssl: added
  * http-useragent: version 1.1.44
  * Terminal-ANSIColor: italic now accessible via the color() sub
  * zef: version 0.4.5

There are some key features of Perl 6 that Rakudo Star does not yet
handle appropriately, although they will appear in upcoming releases.
Some of the not-quite-there features include:

  * advanced macros
  * some bits of Synopsis 9 and 11

There is an online resource at 
that lists the known implemented and missing features of Rakudo's
backends and other Perl 6 implementations.

In many places we've tried to make Rakudo smart enough to inform the
programmer that a given feature isn't implemented, but there are many
that we've missed. Bug reports about missing and broken features are
welcomed at .

See  for links to much more information about
Perl 6, including documentation, example code, tutorials, presentations,
reference materials, design documents, and other supporting resources.
Some Perl 6 tutorials are available under the "docs" directory in
the release tarball.

The development team thanks all of the contributors and sponsors for
making Rakudo Star possible. If you would like to contribute, see
, ask on the 
mailing list, or join us on IRC \#perl6 on freenode.

-- 
Steve Mynott 
cv25519/ECF8B611205B447E091246AF959E3D6197190DD5

[perl6/specs] b08407: s/concatenated/appended/

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: b08407beaae81a63dd7fcbf565dad0fcd44b1b1f
  
https://github.com/perl6/specs/commit/b08407beaae81a63dd7fcbf565dad0fcd44b1b1f
  Author: Elizabeth Mattijsen 
  Date:   2018-05-22 (Tue, 22 May 2018)

  Changed paths:
M S06-routines.pod

  Log Message:
  ---
  s/concatenated/appended/

Concatenation is generally used for strings only.  Seems to me "appending"
describes what happens better.



  **NOTE:** This service been marked for deprecation: 
https://developer.github.com/changes/2018-04-25-github-services-deprecation/

  Functionality will be removed from GitHub.com on January 31st, 2019.

Re: Is negative lookbehind behaving here?

[Timo Paulssen]

Yes, you've encountered a bug. It's got these two tickets:

https://rt.perl.org/Public/Bug/Display.html?id=124898
https://rt.perl.org/Public/Bug/Display.html?id=131964

I've got a branch in nqp and rakudo that I'll merge very soon that fixes
both of these bugs.

Until then you can switch $ and ^, but when the version lands that fixes
the bug, that'll "misbehave" again. I think having ^|$ in the
before/after assertions, i.e. literally match either the beginning or
the end, should work with pre-fix and post-fix versions, as you cannot
have text after the end of the string for example.

Hope that helps!
  - Timo


On 04/05/18 07:38, yary wrote:
> I want to match something anywhere but at the end of a string in one
> example, or anywhere but at the start of a string in another example.
> The "except at start" one has me stumped. Not sure if it's me or if
> I've tickled a bug.
>
> perl6 --version
> This is Rakudo Star version 2018.01 built on MoarVM version 2018.01
> implementing Perl 6.c.
>
> # Match all but at end- this works as I like
> > 'abcd' ~~ m/.+/
> ｢abc｣
>
> # Match all but at start- this puzzles me, 'a' is after the start of
> string but still matches
> > 'abcd' ~~ m/.+/
> ｢abcd｣
>
> # This is a workaround
> > 'abcd' ~~ m/.+/
> ｢bcd｣
>
> Using a perl5 debugger session, roughly translated negative
> lookbehind/lookahead work as I expect.
>
>   DB<1> p 'abcd' =~ /(.+(?!$))/
> abc
>   DB<2> p 'abcd' =~ /((? bcd
>
> -y

Is negative lookbehind behaving here?

[yary]

I want to match something anywhere but at the end of a string in one
example, or anywhere but at the start of a string in another example. The
"except at start" one has me stumped. Not sure if it's me or if I've
tickled a bug.

perl6 --version
This is Rakudo Star version 2018.01 built on MoarVM version 2018.01
implementing Perl 6.c.

# Match all but at end- this works as I like
> 'abcd' ~~ m/.+/
｢abc｣

# Match all but at start- this puzzles me, 'a' is after the start of string
but still matches
> 'abcd' ~~ m/.+/
｢abcd｣

# This is a workaround
> 'abcd' ~~ m/.+/
｢bcd｣

Using a perl5 debugger session, roughly translated negative
lookbehind/lookahead work as I expect.

  DB<1> p 'abcd' =~ /(.+(?!$))/
abc
  DB<2> p 'abcd' =~ /((?

[perl6/specs] cde208: Tweak line number shower

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: cde208bde0f432ee496dabbe556a473c2aa2fcbd
  
https://github.com/perl6/specs/commit/cde208bde0f432ee496dabbe556a473c2aa2fcbd
  Author: Zoffix Znet 
  Date:   2018-03-20 (Tue, 20 Mar 2018)

  Changed paths:
M html/perl-with-historical-message.css

  Log Message:
  ---
  Tweak line number shower

[perl6/specs] 690bf9: Show line number anchors on hover

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 690bf9b60e2a375733ce5508c6aa4cf4999be6af
  
https://github.com/perl6/specs/commit/690bf9b60e2a375733ce5508c6aa4cf4999be6af
  Author: Zoffix Znet 
  Date:   2018-03-20 (Tue, 20 Mar 2018)

  Changed paths:
M html/perl-with-historical-message.css

  Log Message:
  ---
  Show line number anchors on hover

for easy linkage

Re: (default) Real->Rat precision should match what compiler uses for literals

[yary]

I want an epsilon that doesn't confuse newbies and which also is efficient.
epsilon=1/2**(mantissa bits-1) fits the bill.

Why I want this-  It would be great to have numbers survive round-trip
conversions, when feasible.

Specifically I have no need to compare Rats and Nums for equality, but I do
often deal with "flat" text files full of metrics, and remotely sourced
json, and XML. The data types are sometimes unexpected.

-y

On Wed, Mar 7, 2018 at 5:16 PM, Solomon Foster  wrote:

> On Sun, Mar 4, 2018 at 8:49 AM, yary  wrote:
>
>> In that spirit, I'd expect numeric comparison in general, and epsilon
>> specifically, to be set so these return True:
>>
>> > pi == pi.Rat # Does Num to Rat conversion keep its precision?
>> False
>> > pi.Str.Num == pi # Does Num survive string round-trip? - Nothing to do
>> with epsilon
>> False
>>
>>
> Why on earth would you want to do this?
>
> I mean that quite literally.  The only reason I can see for directly
> comparing a Num and a Rat for equality is to check and see if the Rat has
> the same precision as the Num.  In practice, it's well-known you generally
> shouldn't use equality tests on floating point numbers.  Converting one
> side of the equation to a Rat just makes it make even less sense.
>
>
> I've just been playing around with Num to Rat conversion, and here are
> some quick notes.
>
> 1) You can pass 0 as the epsilon for the Rat constructor, which seems to
> be equivalent to very very small values of epsilon.
>
> 2)  pi.Rat(0) + exp(1).Rat(0) is a Rat, but pi.Rat(0) + exp(1).Rat(0) +
> sin(.2).Rat(0) is a Num.  (On the other hand, pi.Rat() + exp(1).Rat() +
> sin(.2).Rat() is still a Rat.)
>
> 3) Remember (I had forgotten!) that Nums can represent numbers much
> smaller than a Rat can.  1e-100 is a perfectly reasonable Num, but (were
> Rat behaving properly) the closest possible Rat value is 0.
>
> 4) That said, if you actually do (1e-100).Rat(0), it gives you (1
> 11590289110975991804683608085639452813897813
> 27557747838772170381060813469985856815104).  Needless to say, that's not
> actually a legal Rat.  Surprisingly (to me, anyway) it is accurate to
> better than 1e-110.
>
> 5) Somewhat more distressingly, (1e+100).Rat gives you (
> 11590289110975991804683608085639452813897813
> 27557747838772170381060813469985856815104 1).  That's only accurate to
> 10**83.  Which is to say, it's as accurate as a double gets -- 16-17
> digits.   (BTW, that is a legal Rat.)
>
> I admit don't really know what to do with this.
>
> --
> Solomon Foster: colo...@gmail.com
> HarmonyWare, Inc: http://www.harmonyware.com
>

Re: (default) Real->Rat precision should match what compiler uses for literals

[Solomon Foster]

On Sun, Mar 4, 2018 at 8:49 AM, yary  wrote:

> In that spirit, I'd expect numeric comparison in general, and epsilon
> specifically, to be set so these return True:
>
> > pi == pi.Rat # Does Num to Rat conversion keep its precision?
> False
> > pi.Str.Num == pi # Does Num survive string round-trip? - Nothing to do
> with epsilon
> False
>
>
Why on earth would you want to do this?

I mean that quite literally.  The only reason I can see for directly
comparing a Num and a Rat for equality is to check and see if the Rat has
the same precision as the Num.  In practice, it's well-known you generally
shouldn't use equality tests on floating point numbers.  Converting one
side of the equation to a Rat just makes it make even less sense.


I've just been playing around with Num to Rat conversion, and here are some
quick notes.

1) You can pass 0 as the epsilon for the Rat constructor, which seems to be
equivalent to very very small values of epsilon.

2)  pi.Rat(0) + exp(1).Rat(0) is a Rat, but pi.Rat(0) + exp(1).Rat(0) +
sin(.2).Rat(0) is a Num.  (On the other hand, pi.Rat() + exp(1).Rat() +
sin(.2).Rat() is still a Rat.)

3) Remember (I had forgotten!) that Nums can represent numbers much smaller
than a Rat can.  1e-100 is a perfectly reasonable Num, but (were Rat
behaving properly) the closest possible Rat value is 0.

4) That said, if you actually do (1e-100).Rat(0), it gives you (1
1159028911097599180468360808563945281389781327557747838772170381060813469985856815104).
Needless to say, that's not actually a legal Rat.  Surprisingly (to me,
anyway) it is accurate to better than 1e-110.

5) Somewhat more distressingly, (1e+100).Rat gives you
(1159028911097599180468360808563945281389781327557747838772170381060813469985856815104
1).  That's only accurate to 10**83.  Which is to say, it's as accurate as
a double gets -- 16-17 digits.   (BTW, that is a legal Rat.)

I admit don't really know what to do with this.

-- 
Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com

Re: (default) Real->Rat precision should match what compiler uses for literals

[yary]

The point of Rats is making Perl6 more correct and less surprising in
common cases, such as
$ perl6
> 1.1+2.2
3.3
> 1.1+2.2 == 3.3
True
> 1.1+2.2 != 3.3
False

vs any language using binary floating-point arithmetic

  DB<1> p 1.1+2.2
3.3
  DB<2> p 1.1+2.2 == 3.3

  DB<3> p 1.1+2.2 != 3.3
1

In that spirit, I'd expect numeric comparison in general, and epsilon
specifically, to be set so these return True:

> pi == pi.Rat # Does Num to Rat conversion keep its precision?
False
> pi.Str.Num == pi # Does Num survive string round-trip? - Nothing to do
with epsilon
False

On the other hand, the original poster Jim and I are both fiddling with the
language to see what it's doing with conversions- I'm are not coming across
this in an application.

What's the greatest value of epsilon that guarantees $x == $x.Rat for all
Num $x - and does that epsilon make denominators that are "too big?" My
understanding of floating point suggests that we should have an epsilon of
1/2**(mantissa bits-1). On a 64-bit platform that's 1/2**52 - for a 32-bit
float that's 1/2**23. Using a 64-bit Rakudo:

> pi.Rat(1/2**52) == pi  # Just enough precision to match this platform's
Num
True
> pi.Rat(1/2**51) == pi  # Epsilon falling a bit short for precision
False

In terms of correctness, epsilon=1/2**(mantissa bits-1) looks like a
winner. Is that acceptable for size and speed?

and digressing, how to make "pi.Str.Num == pi" True?

Re: (default) Real->Rat precision should match what compiler uses for literals

[Solomon Foster]

On Sat, Mar 3, 2018 at 3:32 PM, yary  wrote:

> Or instead of 1/2**(32 or 64), re-asking these questions about epsilon:
>
> "  Why so large?
>
>Why not zero?  "
>
> What's justification for using 1/100,000 vs. something smaller vs. 0 "max
> possible precision?"
>

The problem with using max possible precision is that you will generate a
Rat with a large denominator.  And when you start doing math with those,
the results will usually flip back over to Nums pretty quickly.  But if you
went through the trouble of converting your number from a Num to a Rat,
presumably it's because you wanted to work with Rats, so ending up with a
Num again is a frustrating result.

I don't remember if I was responsible for 1e-6 as the epsilon or not, but
it's quite possible it was me, because in my experience that number is a
common 3D tolerance in CAD software (I believe it's the default in ACIS)
and I tend to grab it for that purpose.  My intuition is that the number
should probably be between 1e-6 and 1e-8, but it would be great if someone
wanted to put in some research/testing to figure out a better value.

It's important to remember that the purpose of Rat in p6 is to dodge around
the common pitfalls of floating point numbers in casual use, while
degrading to Num to prevent your calculations from crawling to a halt when
the denominator gets too big.  For real world measures, a double's 15
digits of accuracy is normally overkill.  (If I'm doing the math right, if
you had a CAD model of the second Death Star in meters, 15 digits would
allow you to specify dimensions to the nanometer.)

If you actually need unbounded precision, then you should be using
FatRats.  One thing I think we absolutely should have is a quick and easy
way to convert from Num to FatRat with minimal loss of precision.  I
believe right now the default Num -> FatRat conversion also uses 1e-6 as an
epsilon, which seems wrong to me.

-- 
Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com

Re: (default) Real->Rat precision should match what compiler uses for literals

[Brandon Allbery]

Max precision rapidly becomes more memory requires than your computer has.

On Sat, Mar 3, 2018 at 3:32 PM, yary  wrote:

> Or instead of 1/2**(32 or 64), re-asking these questions about epsilon:
>
> "  Why so large?
>
>Why not zero?  "
>
> What's justification for using 1/100,000 vs. something smaller vs. 0 "max
> possible precision?"
>



-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net

Re: (default) Real->Rat precision should match what compiler uses for literals

[yary]

Still thinking this out. Does the default epsilon influence a Rat == Float
comparison? If so, for that purpose, the most useful epsilon is one that
maximizes its correctness.

Re: (default) Real->Rat precision should match what compiler uses for literals

[yary]

Or instead of 1/2**(32 or 64), re-asking these questions about epsilon:

"  Why so large?

   Why not zero?  "

What's justification for using 1/100,000 vs. something smaller vs. 0 "max
possible precision?"

Re: (default) Real->Rat precision should match what compiler uses for literals

[yary]

Zeroing in on one point:

> > A solution might be to instead provide a pragmatic, rather than
> mathematical
> > parameter:
> >
> > :$numbits = 64
> >
> > This would say to keep as much precision as possible while making the
> result
> > fit in 64 bits.   For example 2.147483647e0.Rat would result in
> > 2147483647/10 instead of 4310/2007.
>
> The Num type basically has a denominator which is based on 2s, not 10s.
>

The proposal is more-or-less expressible as having epsilon = 2/:numbits -
presuming that the numerator and denominator are about the same size.

>From my POV the default epsilon is fine for practical use, but imprecise
enough to have this conversation come up repeatedly. Search this list for
"$epsilon = 1.0e-6 feels too big for Rat()"

How about setting the default epsilon to 1/2**32 or 1/2**64 and closing
that 2015 New Year's Eve post & this one too?

-y

Re: (default) Real->Rat precision should match what compiler uses for literals

[Brad Gilbert]

On Fri, Mar 2, 2018 at 4:33 PM, Jim Avera  wrote:
> Hello,
>
> Using Rakudo 2018.01:
>
> my Rat  $rat-from-literal = 1.23456789;
> my Rat  $rat-from-str = "1.23456789".Rat;
> my Real $real = 1.23456789e0;
> my Rat  $rat-from-real= $real.Rat;
>
> say $rat-from-literal.nude; # (123456789 1)
> say $rat-from-literal.Str;  # 1.23456789
> say $real.Str;  # 1.23456789
> say $rat-from-str.Str;  # 1.23456789
> say $rat-from-real.Str; # 1.234568   !?!
> say $rat-from-real.nude;# (100 81)
>
> From a user perspective, it's surprising that converting a Real to a Rat is
> by default not as precise as the compiler itself when it converts a literal
> to a Rat.

A Rat is a Real. The Real role only exists so that you can talk about
Numerics while excluding Complex numbers.
You are talking about floating point numbers which are of type Num.

If you change the epsilon to 1/1 they start to return what you expect

> (1.23456789e0,1.2345678e0)».Rat(1/1)
(1.23456789 1.2345678)

> (1.23456789e0,1.2345678e0)».Rat(1/1)».nude».join: '/'
(1356579/1098829 150479/121888)

> In particular, if the exact result can be represented in 64 bits (32-bit
> numerator & denom), throwing  away precision when converting from a 64-bit
> Real has no obvious practical benefit.  That is, throwing away precision
> does not save any memory (assuming Rat uses at least 32+32 -- which is just
> my assumption and might be wrong).

The Rat type uses up to a 64 bit unsigned integer as it's denominator,
the numerator is of arbitrary precision.

> As a programmer, I do not want Perl to throw away information without
> express permission, unless there is a practical necessity to do so, such as
> avoiding exploding memory or computation.

You are asking it to throw out the knowledge that it comes from a Num.

>
> ---
>
> I think the underlying problem is that Real to Rat conversion precision is
> controlled by an "epsilon" value which defaults to 1.0e-6 (see
> https://docs.perl6.org/routine/Rat).
>
> One could argue with the choice of default, but there may not exist an
> appropriate default which always DWIM!
>
> The reason is that I as a programmer don't actually want to limit precision
> per se; I only want to limit memory consumed by the result, and perhaps the
> cpu time needed to operate on that result.
>
> ---
>
> A solution might be to instead provide a pragmatic, rather than mathematical
> parameter:
>
> :$numbits = 64
>
> This would say to keep as much precision as possible while making the result
> fit in 64 bits.   For example 2.147483647e0.Rat would result in
> 2147483647/10 instead of 4310/2007.

The Num type basically has a denominator which is based on 2s, not 10s.
So the runtime has no idea that you expected it to have a denominator of
10 vs 1052513.

This number doesn't start stringifying to what you expect until it gets
an epsilon of 1/100

> $_ = 2.147483647e0.Rat(1/100)
2.147483647
> .nude.join: '/'
22602551/1052513

> If a mathematical epsilon is really what some programmers want (I'm
> doubtful), then both options could be provided:
>
> multi method Rat(Real:D: Real $epsilon)  # no default, used only if
> user really wants it
> multi method Rat(Real:D: Int $maxbits = 64)  # provides the default
> behavior
>
> I would appreciate any comments/explanations/insight on this topic!

Let's say that .Rat converts a Num to every last bit of precision it can.
The result could be so accurate that as soon as you do just about any
operation to it, it goes beyond what can be held in a Rat and becomes a Num.
(depending on the value)

For every one of the examples you have, it would do what you expect
if you converted to a Str before converting to a Rat.

> 1.23456789e0.Str.Rat
1.23456789
> 2.147483647e0.Str.Rat
2.147483647

At any rate the reason Real exists is so that you can accept any of
Rat / Num / Int

There could be a better default behaviour, but you haven't detailed
an algorithm to do it.

Re: Naming debate- what's the location for it?

[Timo Paulssen]

FWIW, Jupyter can also be used with Perl 6, though surely we ought to
advertise it more broadly.

Re: Naming debate- what's the location for it?

[vijayvithal jahagirdar]

While I am not an expert in R, My observation about the specific features
that I use often in R and its equivalence in Perl is as follows.

   - The *apply functions, Technically it is similar to Perl's map/grep and
   friends.
   - Magrittr: Perl5 has no equivalent function, Perl6 has the pipe
   operator ==>
   - the tidyverse set of packages, Python has stolen some of the features
   from this package (ggplot and dplyr) I am not aware of any equivalent
   package in Perl.
   - Literate Programming via knitr ( Python has Jupyter) The nearest
   equivalent I find in Perl is one of the template engines but it is really
   not the same...

I suspect that while P6 has the nuts and bolts of being a great language
for DataScience, It does not provide a complete out of the box experience.

For me to consider P6 instead of R for my Data Analytics, At a minimum I
would prefer to have the equivalent of the tidyverse package,Leaflet and
associated GIS packages and knitr(Which already supports Perl)

Regards

Vijay

On Tue, Feb 20, 2018 at 9:36 PM, yary  wrote:

> A bit of a digression around marketing/evangelizing
>
>
>> When I wanted to learn DataScience, courses using R and Python were
>> readily available. Even though I had been using Perl for 20 years, I did
>> not even know where to start in the Perl ecosystem!
>>
>
> I've wondered why PDL isn't more popular, more of a thing in the wide
> world of science. https://metacpan.org/pod/PDL
>
> And PDL was very much in mind during the early & mid design stages of
> Perl6. There's a huge opportunity for Perl6 to be a great platform for data
> science if it can add PDL's data-crunching performance & expressiveness to
> its already wonderful concurrency models.
>
> -y
>
>


-- 
https://www.facebook.com/vijayvithal.jahagirdar
https://twitter.com/jahagirdar_vs
http://democracies-janitor.blogspot.in/

Re: Naming debate- what's the location for it?

[yary]

A bit of a digression around marketing/evangelizing


> When I wanted to learn DataScience, courses using R and Python were
> readily available. Even though I had been using Perl for 20 years, I did
> not even know where to start in the Perl ecosystem!
>

I've wondered why PDL isn't more popular, more of a thing in the wide world
of science. https://metacpan.org/pod/PDL

And PDL was very much in mind during the early & mid design stages of
Perl6. There's a huge opportunity for Perl6 to be a great platform for data
science if it can add PDL's data-crunching performance & expressiveness to
its already wonderful concurrency models.

-y

RE: Naming debate- what's the location for it?

[Eaglestone, Robert J]

Thank you for your insightful comment Vijay.  You’re right.

Perl6’s evangelists will typically be current Perlers who are running up 
against Perl5’s limitations.

So I think you’ve circumscribed the issue: what is Perl6 for?


  *   Perl6 could be “better than Go” for microservices – IF it’s easy to do 
that.
  *   Perl6 could be “better than Scala” for concurrency – IF it’s better than 
Scala at it.
  *   Perl6 could be good for text processing.  But I don’t know how Rules work.
  *   Bio-Informatics would be great – IF Perl5 is limiting their scope and P6 
opens it back up.
  *   I am having trouble seeing Perl6 as a sysadmin glue language.

In my opinion, the first evangelists are more likely to be microservice and 
concurrency coders than enterprise coders.


From: vijayvithal jahagirdar [mailto:jahagirdar...@gmail.com]
Sent: Saturday, February 17, 2018 1:05 AM
To: Darren Duncan 
Cc: Perl Language ; raiph mellor 

Subject: Re: Naming debate- what's the location for it?

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.
Marketing is not only about branding. It is also about finding Evangelists.
Perl's traditional base was in

  *   Web Development,
  *   Text Processing,
  *   Bio-Informatics and
  *   As a general glue language among the sys admin and EDA community.

How many of these sectors are moving away or have moved away from Perl? What is 
the game plan for bringing them back?

  *   How many courses are there today on Coursera or Other MOOCS which use 
Perl to teach one of the above?
  *   If I wanted to learn something new today, rather than plod through 300 
pages of a book I would signup for a course and spend the time in watching the 
course material and doing the assignments.
  *   When I wanted to learn DataScience, courses using R and Python were 
readily available. Even though I had been using Perl for 20 years, I did not 
even know where to start in the Perl ecosystem!

I believe along with re branding we also need powerful narratives about how 
Modern Perl and P6 are better than their competitors in the selected domains.

Regards

Vijay

On Sat, Feb 17, 2018 at 3:26 AM, Darren Duncan 
> wrote:
If we assume the use of NQP is part of the project's identity, then yes that 
makes sense.  Historically that wasn't the case, eg the earlier Rakudo were 
written to Parrot PIR directly, and there's the possibility this could change 
again, though I see that as unlikely.  Not a bad idea. -- Darren Duncan

On 2018-02-16 3:07 AM, Lloyd Fournier wrote:
I'm about to publish some blog posts with using Perl 6  to demonstrate some 
cryptographic primitives. I was thinking about calling it "rakudo" to at least 
intrigue people and make them google it. Couldn't we call the language rakudo 
and the implementation nqp-rakudo? (ie a rakudo implementation in nqp)

LL


On Thu, Feb 15, 2018 at 5:02 AM Patrick R. Michaud wrote:

On Wed, Feb 14, 2018 at 05:55:54PM +, raiph mellor wrote:
 > (Perl) Rakudo
 > ===
 >
 > If jnthn and pmichaud and larry can warm to this idea, then:
 > [...]
 > The 'Perl' could be dropped from Rakudo specific propaganda,
 > calling the language just Rakudo instead, to reinforce that it refers
 > to 6e and beyond. But the Perl could be retained in any material
 > covering both Raptor and Rakudo as a reunified tech / community.

FWIW, I am VERY MUCH AGAINST the idea of naming a language after its
implementation.  I've seen the confusion it causes in other environments and
we ought not repeat that mistake here, especially since we don't have to.

Whatever things end up being called, don't confuse the implementation(s)
with the language definition.

Pm



--
https://www.facebook.com/vijayvithal.jahagirdar
https://twitter.com/jahagirdar_vs
http://democracies-janitor.blogspot.in/

Re: Naming debate- what's the location for it?

[vijayvithal jahagirdar]

Marketing is not only about branding. It is also about finding Evangelists.
Perl's traditional base was in

   - Web Development,
   - Text Processing,
   - Bio-Informatics and
   - As a general glue language among the sys admin and EDA community.

How many of these sectors are moving away or have moved away from Perl?
What is the game plan for bringing them back?

   - How many courses are there today on Coursera or Other MOOCS which use
   Perl to teach one of the above?
   - If I wanted to learn something new today, rather than plod through 300
   pages of a book I would signup for a course and spend the time in watching
   the course material and doing the assignments.
   - When I wanted to learn DataScience, courses using R and Python were
   readily available. Even though I had been using Perl for 20 years, I did
   not even know where to start in the Perl ecosystem!

I believe along with re branding we also need powerful narratives about how
Modern Perl and P6 are better than their competitors in the selected
domains.

Regards

Vijay

On Sat, Feb 17, 2018 at 3:26 AM, Darren Duncan 
wrote:

> If we assume the use of NQP is part of the project's identity, then yes
> that makes sense.  Historically that wasn't the case, eg the earlier Rakudo
> were written to Parrot PIR directly, and there's the possibility this could
> change again, though I see that as unlikely.  Not a bad idea. -- Darren
> Duncan
>
> On 2018-02-16 3:07 AM, Lloyd Fournier wrote:
>
>> I'm about to publish some blog posts with using Perl 6  to demonstrate
>> some cryptographic primitives. I was thinking about calling it "rakudo" to
>> at least intrigue people and make them google it. Couldn't we call the
>> language rakudo and the implementation nqp-rakudo? (ie a rakudo
>> implementation in nqp)
>>
>> LL
>>
>>
>> On Thu, Feb 15, 2018 at 5:02 AM Patrick R. Michaud wrote:
>>
>> On Wed, Feb 14, 2018 at 05:55:54PM +, raiph mellor wrote:
>>  > (Perl) Rakudo
>>  > ===
>>  >
>>  > If jnthn and pmichaud and larry can warm to this idea, then:
>>  > [...]
>>  > The 'Perl' could be dropped from Rakudo specific propaganda,
>>  > calling the language just Rakudo instead, to reinforce that it
>> refers
>>  > to 6e and beyond. But the Perl could be retained in any material
>>  > covering both Raptor and Rakudo as a reunified tech / community.
>>
>> FWIW, I am VERY MUCH AGAINST the idea of naming a language after its
>> implementation.  I've seen the confusion it causes in other
>> environments and
>> we ought not repeat that mistake here, especially since we don't have
>> to.
>>
>> Whatever things end up being called, don't confuse the
>> implementation(s)
>> with the language definition.
>>
>> Pm
>>
>>


-- 
https://www.facebook.com/vijayvithal.jahagirdar
https://twitter.com/jahagirdar_vs
http://democracies-janitor.blogspot.in/

Re: A proposal for Perl's branding - let's free all the butterflies

[Darren Duncan]

On 2018-02-16 11:15 AM, Nigel Hamilton wrote:

Here is a suggestion for Perl's branding:

http://nigelhamilton.com/perl-branding-proposal.html


I like your proposal.

But its details would need fleshing out more, particularly at the end, where it 
says this:


Perl $new_runtime_name_for_perl5_goes_here (tm)
Perl $new-runtime-name-for-perl6-goes-here (tm)

That implies that the only things being branded this way are runtimes, and not 
the languages themselves, which I thought was meant to be under that umbrella.


So for example:

Perl $new_language_name_for_perl5_goes_here (tm)
Perl $new-language-name-for-perl6-goes-here (tm)

-- Darren Duncan

A proposal for Perl's branding - let's free all the butterflies

[Nigel Hamilton]

Here is a suggestion for Perl's branding:

http://nigelhamilton.com/perl-branding-proposal.html

Re: Naming debate- what's the location for it?

[Lloyd Fournier]

I'm about to publish some blog posts with using Perl 6  to demonstrate some
cryptographic primitives. I was thinking about calling it "rakudo" to at
least intrigue people and make them google it. Couldn't we call the
language rakudo and the implementation nqp-rakudo? (ie a rakudo
implementation in nqp)

LL


On Thu, Feb 15, 2018 at 5:02 AM Patrick R. Michaud 
wrote:

> On Wed, Feb 14, 2018 at 05:55:54PM +, raiph mellor wrote:
> > (Perl) Rakudo
> > ===
> >
> > If jnthn and pmichaud and larry can warm to this idea, then:
> > [...]
> > The 'Perl' could be dropped from Rakudo specific propaganda,
> > calling the language just Rakudo instead, to reinforce that it refers
> > to 6e and beyond. But the Perl could be retained in any material
> > covering both Raptor and Rakudo as a reunified tech / community.
>
> FWIW, I am VERY MUCH AGAINST the idea of naming a language after its
> implementation.  I've seen the confusion it causes in other environments
> and we ought not repeat that mistake here, especially since we don't have
> to.
>
> Whatever things end up being called, don't confuse the implementation(s)
> with the language definition.
>
> Pm
>

Re: Naming debate- what's the location for it?

[raiph mellor]

Another 2 or 3 pennies^1 worth of strawman proposing / bikeshedding /
flight of marketing fancy about naming etc:

Perl's Rapture
===

Imagine we officially embarked on a year+ long communal process in
which we (TPF and Perl community) sort out branding and marketing of
Perlish languages. A key goal is to have everything as clear as we can
manage before Python 2.x official EOL. We not only make it clear how
P5 and P6 are different and how they are related but also how they sit
in contrast to Python, C/C++, Java, JS and other langs trying to evolve.

I think "Perl's Rapture" would be a fun and helpful name for this process.
I'm an atheist, or nearly so, but I can't think of something that beats the
several fun and interesting elements/parallels I see in the Wikipedia intro
in its Rapture page.^2

Perl Raptor
=

This is my proposal for Perl 5.30 and beyond.

It's an existing semi-official alternate name for P5, with a logo
hosted at TPF's website.^3

The 'Perl' could generally / increasingly be dropped from propaganda,
calling the language just Raptor instead, when that's helpful for reinforcing
that it's officially for refering to 5.30 and beyond.

I'm thinking there would be a switch from use of the Velociraptor to a
raptor bird logo, with a new logo competition, emphasizing smallness,
evolutionary fitness, speed etc, but perhaps I'm now weighing in with
3p instead of 2p and that might be a tad too rich.

(Perl) Rakudo
===

If jnthn and pmichaud and larry can warm to this idea, then:

This is my proposal for 6e+ (My sense is we'd be better off letting
P6 mature for another couple years, avoid unduly undercutting the
wave of books with Perl 6 in their title, and wait till after we get a
round of Perl Raptor branding impact / marketing, and instead hold
the noisy push till 6e around the time Python folk EOL Python 2.x.)

The 'Perl' could be dropped from Rakudo specific propaganda,
calling the language just Rakudo instead, to reinforce that it refers
to 6e and beyond. But the Perl could be retained in any material
covering both Raptor and Rakudo as a reunified tech / community.

-

^1 I've just arrived back in Britain after 25 years in the US.

^2 Excerpts from https://en.wikipedia.org/wiki/Rapture intro:

The Rapture is an eschatological term used by certain Christians ...

... meaning to snatch away or seize
[from what?]

... used by certain believers ... viewing it as preceding the Second
Coming and followed by a thousand year millennial kingdom
[cf 100 year language]

... there are differing viewpoints about the exact timing of the purported event
[at official Python 2.x EOL?]

... There are differing views ... whether it will occur in one event or two
[Raptor relaunch of P5... Rakudo relaunch of P6...]

... the term "rapture" is derived from the text of the Latin ... —"we
will be caught up"
[It's going to be fascinating to see what happens in 2020s re Python vs Perl in
particular and Hindley Milner static typing vs nominal static/dynamic typing]

^3 http://news.perlfoundation.org/2012/12/the-first-twenty-five-years.html

love to all, raiph

Re: Naming debate- what's the location for it?

[Ruud H.G. van Tol]

Don't type here.

On 2018-02-10 05:16, Parrot Raiser wrote:

On 2/10/18, Darren Duncan  wrote:



I think if we want to keep "Perl" in the name we should use "C" as a precedent.
Other related languages keeping "C" include "Objective C", "C#", "C++",


Perl++ would work.


https://en.wikipedia.org/wiki/Perl_6
doesn't explain well what makes "Perl_6" special and convenient.

Have a list of specialties, like:
- hyper-operators
- ...

and then use that to inspire a name, like:

PerlZ (toothpaste)
https://duckduckgo.com/?q=%22perlz%22+-perla=ffab=web

*HyPerl*
https://duckduckgo.com/?q=%22hyperl%22+-hyper+-hyperlink+-hyperlinks+-hyperlipidemia+-hyperlite+-hyperloop+-hyperlynx+-hypertension=ffab=web

Plector (in use)
https://en.wiktionary.org/wiki/plector

Mu-Perl https://en.wikipedia.org/wiki/Mu_(letter)

Perlite https://en.wikipedia.org/wiki/Perlite

Perlang https://www.google.com.my/maps/place/Perlang

Etc.

I still like 'Onion'.
And 'Perl6' (without any separator).


-- Greetings, Ruud

So also think about search engines. Remember "go, golang" (IMO DOA).

Re: Naming debate- what's the location for it?

[Parrot Raiser]

On 2/10/18, Darren Duncan  wrote:

> I think if we want to keep "Perl" in the name we should use "C" as a 
> precedent.
> Other related languages keeping "C" include "Objective C", "C#", "C++",
> >

Perl++ would work.

Re: Naming debate- what's the location for it?

[Steve Pitchford]

Ok. So here is something revolutionary.

Free up "Perl 6" for a future generation of Perl 5 and remove the ceiling
on the perl 5 language. Perl 6 has become more than a major iteration,
hasn't it?

Perl on parrot
Perl on jam
Perl on mono

Lots of space for a five from six once you vacate the lot.

Reposition as not so much a sequel as a spin off, a "b side". Some b-sides
have eclipsed the inspiration. Sometimes letting go is what counts.

Steve

( I continually admire from afar what has been achieved and surfaced in the
voyage of discovery that is YOUR language )


On 9 Feb 2018 10:34 pm, "Darren Duncan"  wrote:

> On 2018-02-09 12:55 PM, Eaglestone, Robert J wrote:
>
>> I think a name change is too radical. /And yet/.
>>
>> I think Steve has a point, though I don’t know what to do about it.  The
>> developers in my little corner of the world may not be up on the
>> new-language-of-the-week, but even they see Perl as a has-been, write-only
>> language, so when their brain matches /perl/i they automatically toss it in
>> the bit bucket.  Some of them are too nice to say it outright.  Some aren’t.
>>
>
> Personally I think having the "6" as part of the name is the worst part of
> the situation.  Its too confusing with a version number.
>
> I think if we want to keep "Perl" in the name we should use "C" as a
> precedent. Other related languages keeping "C" include "Objective C", "C#",
> "C++", and its much more clear those are separate languages, even if
> C-alike.
>
> So one way or another, "6" should be dropped from the name of the language
> formally.  Then we either have "Foo Perl" or "Perl Foo" or "Foo".
>
> After this is done, regular "Perl" can also be free to increment its first
> version number for major releases (albeit skipping 6 to avoid confusion)
> just as Postgres and many other projects do these days, as staying at 5.x
> forever is weird.
>
> -- Darren Duncan
>

RE: Naming debate- what's the location for it?

[Eaglestone, Robert J]

I think a name change is too radical.  And yet.

I think Steve has a point, though I don’t know what to do about it.  The 
developers in my little corner of the world may not be up on the 
new-language-of-the-week, but even they see Perl as a has-been, write-only 
language, so when their brain matches /perl/i they automatically toss it in the 
bit bucket.  Some of them are too nice to say it outright.  Some aren’t.

Six.

From: Steve Pitchford [mailto:steve.pitchf...@gmail.com]
Sent: Friday, February 09, 2018 2:08 PM
To: Lucas Buchala 
Cc: Perl6 
Subject: Re: Naming debate- what's the location for it?

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.
Thought the conversation felt like bikeshedding but... My point still stands. 
This is a new language targetted at a post php world. The significance of a 
version number will be lost outside the perl echo chamber and in that context 
seen as baggage... IMHO... YMMV...

On 9 Feb 2018 6:15 pm, "Lucas Buchala" 
> wrote:
I doubt the name is "up for discussion" just because there's a blog
post about it. The name ain't changing ever, or at least that's how I
understand things. But, please, feel free to correct me if I'm wrong.

Sure, you can have as many alternative nicknames and aliases as you
want (for marketing purposes?), but the official name won't change.
So, move on, folks.

Re: Naming debate- what's the location for it?

[Steve Pitchford]

Thought the conversation felt like bikeshedding but... My point still
stands. This is a new language targetted at a post php world. The
significance of a version number will be lost outside the perl echo chamber
and in that context seen as baggage... IMHO... YMMV...

On 9 Feb 2018 6:15 pm, "Lucas Buchala"  wrote:

I doubt the name is "up for discussion" just because there's a blog
post about it. The name ain't changing ever, or at least that's how I
understand things. But, please, feel free to correct me if I'm wrong.

Sure, you can have as many alternative nicknames and aliases as you
want (for marketing purposes?), but the official name won't change.
So, move on, folks.

Re: Naming debate- what's the location for it?

[Lucas Buchala]

I doubt the name is "up for discussion" just because there's a blog
post about it. The name ain't changing ever, or at least that's how I
understand things. But, please, feel free to correct me if I'm wrong.

Sure, you can have as many alternative nicknames and aliases as you
want (for marketing purposes?), but the official name won't change.
So, move on, folks.

Re: Naming debate- what's the location for it?

[Parrot Raiser]

Looking at possible candidates from a search-engine results and
alternative manings test. some possible choices:
 Mu,  (the root object class),
Camelia, (the spokesbug taking over),
Shesh, (the female form of 6 in Hebrew, but unfortunately also in the
Urban Dictionary - look it up for yourself).



On 2/9/18, Steve Pitchford  wrote:
> Well, for what it's worth, as an outsider - IMHO, leaving "perl" behinds a
> good thing. Love it or loath it, we live in a js/python/jvm leaning world.
> Perl was great, but it's dated. Why have the baggage? Rakudo is a new
> language. Treat it as such - best hope for it. In layman's terms an
> informal "Perl V2", ridiculous as that may be to the community.
>
> Steve
>
> On 8 Feb 2018 10:18 pm, "Darren Duncan"  wrote:
>
> My personal favorite resolution is to officially name the language Rakudo,
> full stop.
>
> The implementation that was/is using the name would be renamed to something
> else so it isn't the same as the language.
>
> Then we say "Rakudo" is a sibling language of "Perl", full stop.
>
> Then "Perl 6" becomes a deprecated alias for Rakudo, used informally rather
> than formally from now on, and officially considered a historical footnote
> rather than anything still cited in official documentation or marketing.
>
> The unqualified name "Perl" continues to refer to the original lineage
> (currently at version 5.x) such as what 99% of the world means when they
> refer to it.
>
> Remember, we can still say "Rakudo is a sibling of Perl" for all the
> reasons we currently do without actually calling it any kind of "Perl" as
> an individual; we don't actually lose the family thing.
>
> For documentation/marketing materials and to help with continuity, we can
> typically reference "the Rakudo language, a sibling of Perl", where the
> latter part is then more of a description.
>
> This is what I really think should and that I would like to happen.
>
> -- Darren Duncan
>
> On 2018-02-08 12:47 PM, yary wrote:
>
>> ...and "rakudo" even better by that criterion. And then there's how
>> "rakudo" is already named in many files, databases, websites, and that's
>> enough to make me think it's a "good enough" name. Though I'd like to
>> change that implementation's name to something else if we start calling
>> the
>> language Rakudo!
>>
>>
>> I quite like having the distinction between the language and its
>> implementations. No one confuses C with cc, gcc, pcc, tcc, mvcc, XCode,
>> or
>> Borland. Using the name "rakudo" to mean the language makes me feel a
>> little bad in that it muddies that distinction further, and gives this
>> current implementation a special status. A status which it earned, we're
>> not talking about calling the Perl6 language "pugs" or "parrot" or
>> "niecza"
>> for a reason. /me shrugs.
>>
>

Re: Naming debate- what's the location for it?

[Steve Pitchford]

Well, for what it's worth, as an outsider - IMHO, leaving "perl" behinds a
good thing. Love it or loath it, we live in a js/python/jvm leaning world.
Perl was great, but it's dated. Why have the baggage? Rakudo is a new
language. Treat it as such - best hope for it. In layman's terms an
informal "Perl V2", ridiculous as that may be to the community.

Steve

On 8 Feb 2018 10:18 pm, "Darren Duncan"  wrote:

My personal favorite resolution is to officially name the language Rakudo,
full stop.

The implementation that was/is using the name would be renamed to something
else so it isn't the same as the language.

Then we say "Rakudo" is a sibling language of "Perl", full stop.

Then "Perl 6" becomes a deprecated alias for Rakudo, used informally rather
than formally from now on, and officially considered a historical footnote
rather than anything still cited in official documentation or marketing.

The unqualified name "Perl" continues to refer to the original lineage
(currently at version 5.x) such as what 99% of the world means when they
refer to it.

Remember, we can still say "Rakudo is a sibling of Perl" for all the
reasons we currently do without actually calling it any kind of "Perl" as
an individual; we don't actually lose the family thing.

For documentation/marketing materials and to help with continuity, we can
typically reference "the Rakudo language, a sibling of Perl", where the
latter part is then more of a description.

This is what I really think should and that I would like to happen.

-- Darren Duncan

On 2018-02-08 12:47 PM, yary wrote:

> ...and "rakudo" even better by that criterion. And then there's how
> "rakudo" is already named in many files, databases, websites, and that's
> enough to make me think it's a "good enough" name. Though I'd like to
> change that implementation's name to something else if we start calling the
> language Rakudo!
>
>
> I quite like having the distinction between the language and its
> implementations. No one confuses C with cc, gcc, pcc, tcc, mvcc, XCode, or
> Borland. Using the name "rakudo" to mean the language makes me feel a
> little bad in that it muddies that distinction further, and gives this
> current implementation a special status. A status which it earned, we're
> not talking about calling the Perl6 language "pugs" or "parrot" or "niecza"
> for a reason. /me shrugs.
>

Re: Naming debate- what's the location for it?

[Darren Duncan]

My personal favorite resolution is to officially name the language Rakudo, full 
stop.


The implementation that was/is using the name would be renamed to something else 
so it isn't the same as the language.


Then we say "Rakudo" is a sibling language of "Perl", full stop.

Then "Perl 6" becomes a deprecated alias for Rakudo, used informally rather than 
formally from now on, and officially considered a historical footnote rather 
than anything still cited in official documentation or marketing.


The unqualified name "Perl" continues to refer to the original lineage 
(currently at version 5.x) such as what 99% of the world means when they refer 
to it.


Remember, we can still say "Rakudo is a sibling of Perl" for all the reasons we 
currently do without actually calling it any kind of "Perl" as an individual; we 
don't actually lose the family thing.


For documentation/marketing materials and to help with continuity, we can 
typically reference "the Rakudo language, a sibling of Perl", where the latter 
part is then more of a description.


This is what I really think should and that I would like to happen.

-- Darren Duncan

On 2018-02-08 12:47 PM, yary wrote:
...and "rakudo" even 
better by that criterion. And then there's how "rakudo" is already named in many 
files, databases, websites, and that's enough to make me think it's a "good 
enough" name. Though I'd like to change that implementation's name to something 
else if we start calling the language Rakudo!


I quite like having the distinction between the language and its 
implementations. No one confuses C with cc, gcc, pcc, tcc, mvcc, XCode, or 
Borland. Using the name "rakudo" to mean the language makes me feel a little bad 
in that it muddies that distinction further, and gives this current 
implementation a special status. A status which it earned, we're not talking 
about calling the Perl6 language "pugs" or "parrot" or "niecza" for a reason. 
/me shrugs.

RE: Naming debate- what's the location for it?

[Eaglestone, Robert J]

  *   What's the counter word for computer languages, anyway?

-mai?  As an abstraction from paper printouts?


From: Brent Laabs [mailto:bsla...@gmail.com]
Sent: Thursday, February 08, 2018 2:51 PM
To: Aaron Sherman 
Cc: yary ; Perl6 
Subject: Re: Naming debate- what's the location for it?

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.
Thanks for the summary of the high points, as there were a large number of low 
points in previous discussions.

Roku is not the only reading for 六 in Japanese, the kun reading is muttsu.  So 
we could become Mupperl.  What's the counter word for computer languages, 
anyway?


On Thu, Feb 8, 2018 at 12:15 PM, Aaron Sherman 
> wrote:
I think this is a fine place, personally. Past discussions have included these 
high points as I recall them:


  1.  Perl is definitely the family name
  2.  Rakudo started out as the name of an implementation, but started to 
wander into being the name of the specific leaf in the family tree
  3.  Problem is that that leaves us uncertain of the status of 
non-Rakudo-the-implementation implementations. Are they now Rakudo too? That's 
confusing at best.

IMHO, 6 has always been the personal name, but it could be changed to something 
that's "sixish" without being an explicit number. Normally, I'd recommend 
Latin, but Perl Sex is probably not where anyone wants to go...  Roku is 
Japanese, but also the name of a popular device, and thus confusing...






--
Aaron Sherman, M.:
P: 617-440-4332 // E: a...@ajs.com
Toolsmith, developer, gamer and life-long student.

On Thu, Feb 8, 2018 at 10:41 AM, yary 
> wrote:
I recall coming across a post saying the Perl6 name is up for discussion - 
searched & found this post now 
https://6lang.party/post/The-Hot-New-Language-Named-Rakudo
 describes it. Is there a forum where the name's being discussed that I can 
read?
Woke up this morning with a name proposal that seemed to have a lot going for 
it, but from that post it seems Lizmat et al have a good choice already & I 
don't want to add to bikeshedding... wondering what the thinking is right now.

-y

Re: Naming debate- what's the location for it?

[Aaron Sherman]

Just Mu would be an amusing Perlish pun based on Muttsu... Making the
interpretation either Perl "six" or Perl "most undefined".

I like yary's idea too.

Frankly, if Perl had an identity, I would not care about the name. I feel
like it lacks that right now.




--
Aaron Sherman, M.:
P: 617-440-4332 // E: a...@ajs.com
Toolsmith, developer, gamer and life-long student.

On Thu, Feb 8, 2018 at 3:50 PM, Brent Laabs  wrote:

> Thanks for the summary of the high points, as there were a large number of
> low points in previous discussions.
>
> Roku is not the only reading for 六 in Japanese, the kun reading is
> muttsu.  So we could become Mupperl.  What's the counter word for computer
> languages, anyway?
>
>
>
> On Thu, Feb 8, 2018 at 12:15 PM, Aaron Sherman  wrote:
>
>> I think this is a fine place, personally. Past discussions have included
>> these high points as I recall them:
>>
>>
>>1. Perl is definitely the family name
>>2. Rakudo started out as the name of an implementation, but started
>>to wander into being the name of the specific leaf in the family tree
>>3. Problem is that that leaves us uncertain of the status of
>>non-Rakudo-the-implementation implementations. Are they now Rakudo too?
>>That's confusing at best.
>>
>>
>> IMHO, 6 has always been the personal name, but it could be changed to
>> something that's "sixish" without being an explicit number. Normally, I'd
>> recommend Latin, but Perl Sex is probably not where anyone wants to go...
>> Roku is Japanese, but also the name of a popular device, and thus
>> confusing...
>>
>>
>>
>>
>>
>>
>> --
>> Aaron Sherman, M.:
>> P: 617-440-4332 <(617)%20440-4332> // E: a...@ajs.com
>> Toolsmith, developer, gamer and life-long student.
>>
>> On Thu, Feb 8, 2018 at 10:41 AM, yary  wrote:
>>
>>> I recall coming across a post saying the Perl6 name is up for discussion
>>> - searched & found this post now https://6lang.party/post/The-H
>>> ot-New-Language-Named-Rakudo describes it. Is there a forum where the
>>> name's being discussed that I can read?
>>>
>>> Woke up this morning with a name proposal that seemed to have a lot
>>> going for it, but from that post it seems Lizmat et al have a good choice
>>> already & I don't want to add to bikeshedding... wondering what the
>>> thinking is right now.
>>>
>>> -y
>>>
>>
>>
>

Re: Naming debate- what's the location for it?

[Brent Laabs]

Thanks for the summary of the high points, as there were a large number of
low points in previous discussions.

Roku is not the only reading for 六 in Japanese, the kun reading is muttsu.
So we could become Mupperl.  What's the counter word for computer
languages, anyway?



On Thu, Feb 8, 2018 at 12:15 PM, Aaron Sherman  wrote:

> I think this is a fine place, personally. Past discussions have included
> these high points as I recall them:
>
>
>1. Perl is definitely the family name
>2. Rakudo started out as the name of an implementation, but started to
>wander into being the name of the specific leaf in the family tree
>3. Problem is that that leaves us uncertain of the status of
>non-Rakudo-the-implementation implementations. Are they now Rakudo too?
>That's confusing at best.
>
>
> IMHO, 6 has always been the personal name, but it could be changed to
> something that's "sixish" without being an explicit number. Normally, I'd
> recommend Latin, but Perl Sex is probably not where anyone wants to go...
> Roku is Japanese, but also the name of a popular device, and thus
> confusing...
>
>
>
>
>
>
> --
> Aaron Sherman, M.:
> P: 617-440-4332 <(617)%20440-4332> // E: a...@ajs.com
> Toolsmith, developer, gamer and life-long student.
>
> On Thu, Feb 8, 2018 at 10:41 AM, yary  wrote:
>
>> I recall coming across a post saying the Perl6 name is up for discussion
>> - searched & found this post now https://6lang.party/post/The-H
>> ot-New-Language-Named-Rakudo describes it. Is there a forum where the
>> name's being discussed that I can read?
>>
>> Woke up this morning with a name proposal that seemed to have a lot going
>> for it, but from that post it seems Lizmat et al have a good choice already
>> & I don't want to add to bikeshedding... wondering what the thinking is
>> right now.
>>
>> -y
>>
>
>