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
>

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.

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?
> 

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.

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
> 

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
>

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?

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

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

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. :-)*

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

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

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 <not@gmail.com> 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 <not@gmail.com> 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 <dar...@darrenduncan.net>
Cc: Perl Language <perl6-language@perl.org>; raiph mellor 
<raiph.mel...@gmail.com>
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 
<dar...@darrenduncan.net<mailto:dar...@darrenduncan.net>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_vijayvithal.jahagirdar=DwMFaQ=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0=YVtxbf12RluVb8ADnHy_ofdMa_3_X_0rVHmYLjfLBqc=eEYEh2nqWqWaPBSw8-laGZpox5xmyAsBGKlm8pKh9l8=o-OvdiB4R0MNj1ebaCgDPXP92A5RzE8l5F4tv8kWNAQ=>
https://twitter.com/jahagirdar_vs<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_jahagirdar-5Fvs=DwMFaQ=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0=YVtxbf12RluVb8ADnHy_ofdMa_3_X_0rVHmYLjfLBqc=eEYEh2nqWqWaPBSw8-laGZpox5xmyAsBGKlm8pKh9l8=WWsY-2wAsp-LXR0c7N_hGkOU-TmYvh_LHBDWnLqTbqQ=>
http://democracies-janitor.blogspot.in/<https://urldefense.proofpoint.com/v2/url?u=http-3A__democracies-2Djanitor.blogspot.in_=DwMFaQ=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0=YVtxbf12RluVb8ADnHy_ofdMa_3_X_0rVHmYLjfLBqc=eEYEh2nqWqWaPBSw8-laGZpox5xmyAsBGKlm8pKh9l8=BrSKvtzA38irul4-AIbsJzZO-uPP9lEqqeZvKr2er54=>

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 <dar...@darrenduncan.net>
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

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 <lucasbuch...@gmail.com>
Cc: Perl6 <perl6-language@perl.org>
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" 
<lucasbuch...@gmail.com<mailto:lucasbuch...@gmail.com>> 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 <a...@ajs.com>
Cc: yary <not@gmail.com>; Perl6 <perl6-language@perl.org>
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 
<a...@ajs.com<mailto:a...@ajs.com>> 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<tel:(617)%20440-4332> // E: a...@ajs.com<mailto:a...@ajs.com>
Toolsmith, developer, gamer and life-long student.

On Thu, Feb 8, 2018 at 10:41 AM, yary 
<not@gmail.com<mailto:not@gmail.com>> 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__6lang.party_post_The-2DHot-2DNew-2DLanguage-2DNamed-2DRakudo=DwMFaQ=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0=YVtxbf12RluVb8ADnHy_ofdMa_3_X_0rVHmYLjfLBqc=xjlt4ZpgJ-W1LhQnUHvj3Ir60-gAB4cJzm8m3z5f5vk=Ybl6ExHYXeEAA-RlYnXA_XgJSLjWzu73tfNi_Sv-loc=>
 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
>>
>
>

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

[yary]

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

> ...
> 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...
>

Greek: ExiPerl / PerlExi (PerlExi sounds a bit like "perl lexer," which is
a good)

but that wasn't my thought for the name update. It started off as a variant
of "Plural" (Plerl) and evolved into "Perls"

- "Perls" looks and sounds like "Perl". It's Perl with one more letter.
- It's a contraction of "Perl six"
- Looking like an English plural noun harkens to the "more than one way to
do it" ethic.
- Looking like an English plural noun hints at the ideal of multiple
implementations.
- Easy to web search without false positives.

The thing is, Zoffix makes the point of moving to a name that doesn't sound
like Perl, by which reasoning "plerl" would be better than "perls", 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?

[Aaron Sherman]

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: Announce: Rakudo Star Release 2017.07

[Mark Devine]

Perl6 Developers,

Thank you for your efforts.  I'm having a great time working with this 
language.  As a systems person, I'm getting the feeling that this might 
actually be the "last language I ever have to learn" (cite: Wall).  My 
cantankerous `command` outputs are now very manageable.  Concurrency is 
bordering on trivial.  My application libraries/APIs are now in reach without 
much effort.  The more I read/experiment, the better the story gets.  Keep your 
steam up and press on.  Worth it!

Thanks,

Mark

-Original Message-
From: Steve Mynott [mailto:steve.myn...@gmail.com] 
Sent: Monday, July 24, 2017 2:40 PM
To: perl6-users ; Perl6 ; 
perl6-compiler 
Subject: Announce: Rakudo Star Release 2017.07

A useful and usable production distribution of Perl 6

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

Binaries for macOS and Windows (64 bit) are also available.

This is the eighth 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).

IMPORTANT: "panda" is to be removed very shortly since it is deprecated. Please 
use "zef" instead.

Currently, Star is on a quarterly release cycle and 2017.10 (October) will 
follow later this year.

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".

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

Note this Star release contains NQP version 2017.07-9-gc0abee7 rather than the 
release NQP 2017.07 in order to fix the --ll-exception command line flag.

The Rakudo compiler changes since the last Rakudo Star release of
2017.01 are now listed in "2017.05.md", "2017.06.md" and "2017.07.md"
under the "rakudo/docs/announce" directory of the source distribution.

Notable changes in modules shipped with Rakudo Star:

+ DBIish: Doc and CI updates
+ doc: Too many to list. p6doc fixed.
+ grammar-debugger: Works again now.
+ p6-io-string: New dep for doc.
+ p6-native-resources: Removed since deprecated and not used by linenoise.
+ panda: Officially deprecate panda in favour of zef.
+ perl6-Test-When: New dep for perl6-pod-to-bigpage.
+ perl6-lwp-simple: Fix breakage due to rakudo encoding refactor.
+ tap-harness6: Replaces deprecated tap-harness6-prove6.
+ zef: Too many to list.

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
+ non-blocking I/O (in progress)
+ 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 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 
http://rakudo.org/how-to-help, ask on the perl6-compi...@perl.org mailing list, 
or join us on IRC #perl6 on freenode.


--
4096R/EA75174B Steve Mynott 

[perl6/specs] 7000e0: Introduce versioning of the META6.json spec for re...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 7000e04e42e3bb31994e5202b52c269457d18dab
  
https://github.com/perl6/specs/commit/7000e04e42e3bb31994e5202b52c269457d18dab
  Author: Stefan Seifert 
  Date:   2017-05-14 (Sun, 14 May 2017)

  Changed paths:
M S22-package-format.pod

  Log Message:
  ---
  Introduce versioning of the META6.json spec for real

Use a more descriptive name of the version field and mark it as
required. Tools will provide some backwards compatibility, but this
document describes the state as it _should_ be at some point in the
future. And there we'll want to have a mandatory meta-version field.

Re: fixing infinities and ranges etc

[Darren Duncan]

On 2016-10-30 4:11 PM, Darren Duncan wrote:

On 2016-10-30 5:45 AM, yary wrote:

Before/AfterEverything are also easy to understand, and would be as natural to
use for sorting strings, eg. for saying if a database NULL should go before the
empty string or after everything else. On the other hand, if I'doing something
with tangents and handling pi/2, I'd rather be thinking about PosInf as my
exception and not AfterEverything.


So, the main thing that I think should exist is a generic
before/after-everything concept so that it can be used to indicate that generic
intervals are unbounded at either end and that generic 'cmp' etc are
automatically defined for every other type and them and use as identity values
for min/max.


So, following up on this, ...

I went with the singleton names Before_All_Others and After_All_Others in my 
abstract database protocol API for Perl 6, and explicitly documented that these 
are a type-agnostic analogy to negative/positive infinity whose sole purpose is 
to canonically sort before or after every other value in the type system, and 
they expressly do NOT represent any mathematical or physical concept of 
infinity, including those in IEEE floating point, which should be defined 
separately where useful.  Example uses of these singletons are to represent the 
endpoints of partially or totally unbounded intervals/ranges, or be the identity 
values for "min" and "max", or be the result when one calls "pred" or "succ" on 
the first/last value of an orderable type.


And so, I also want to propose that Perl 6 add the 2 singletons 
X::BeforeAllOthers and X::AfterAllOthers for similar type-generic use cases. 
Yet other singletons or values can exist to meaningfully represent mathematical 
infinities etc such as the IEEE floats support so appropriate semantics exist in 
peoples' code.


-- Darren Duncan

Re: [PATCH] multiple heredoc beginning in the same line

[Perl6]

it's not so difficult, really. you just gotta know the trick:

- cd into the repository you want, then run "git am".
- Use your mail client's "view source" function (ctrl-u in thunderbird
for example).
- copy the complete mail source including headers
- paste it into the terminal that's running git am
- hit return if necessary, and ctrl-d

done.

I pushed the patch to our repository. Thanks for your work, francois!
  - Timo

Re: [PATCH] multiple heredoc beginning in the same line

[franc...@avalenn.eu]

On Thu, Dec 01, 2016 at 10:15:03AM -0500, Will Coleda wrote:
> This will be much more likely to be applied if you provide a pull
> request to the repo at https://github.com/perl6/doc

I agree but it was a lot simpler for me to send it by e-mail at the moment.
I will perhaps try to make a pull-request when I have time and access
at the same time.

Re: [PATCH] multiple heredoc beginning in the same line

[franc...@avalenn.eu]

On Thu, Dec 01, 2016 at 10:46:17AM -0600, andy_b...@wiwb.uscourts.gov wrote:
> Hmm:
> $ cat /tmp/here.pl6
> my ($first, $second) = qq:to/END1/, qq:to/END2/;
>   FIRST
>   MULTILINE
>   STRING
>   END1
>SECOND
>MULTILINE
>STRING
>END2
> say "f: $first, s: $second";
> 
> $ perl6 /tmp/here.pl6
> f: FIRST
> MULTILINE
> STRING
> , s: SECOND
> MULTILINE
> STRING
> 
> 
> I'd expected $second to have both strings, as its here doc seems to start 
> at "FIRST" and go to END2 ... or am I misreading this?

Freely rephrasing POSIX[1] to adapt it to Perl6 the description could
be :

The first here-document begins after the next  and
continues until there is a line containing only the delimiter
(possibly preceded by spaces) followed immediately by a ,
Then the next here-document starts, if there is one.

So it is expected that $second does not include $first.

[1]: 
http://pubs.opengroup.org/onlinepubs/007904875/utilities/xcu_chap02.html#tag_02_07_04

Re: [PATCH] multiple heredoc beginning in the same line

[Will Coleda]

This will be much more likely to be applied if you provide a pull
request to the repo at https://github.com/perl6/doc

On Wed, Nov 30, 2016 at 10:31 AM,   wrote:
> This is to document the fact that, as in POSIX shell, you can use
> multiple HEREDOC strings in the same line.
>
> ---
>  doc/Language/quoting.pod6 | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/doc/Language/quoting.pod6 b/doc/Language/quoting.pod6
> index f7fe658..393807b 100644
> --- a/doc/Language/quoting.pod6
> +++ b/doc/Language/quoting.pod6
> @@ -386,6 +386,20 @@ would produce:
>file "db.7.3.8";
>};
>
> +You can begin multiple Heredocs in the same line.
> +
> +=begin code
> +my ($first, $second) = qq:to/END1/, qq:to/END2/;
> +  FIRST
> +  MULTILINE
> +  STRING
> +  END1
> +   SECOND
> +   MULTILINE
> +   STRING
> +   END2
> +=end code
> +
>  =head1 Regexes
>
>  For information about quoting as applied in regexes see the L --
> 2.9.3



-- 
Will "Coke" Coleda

Re: CALL-ME vs. Callable

[Brandon Allbery]

I feel like you're focusing on the wrong thing somehow. The issue is not
that what nqp is doing is somehow wrong. The issue is that the thing it is
doing is necessarily an implementation detail, and as such should be
isolated from the language level and any failures/errors exposed as
language level instead of leaking implementation details the programmer
should not have to care about. The Perl 6 way to do this is to wrap it in a
role that is documented at language level; in this case, I don't think it
is necessary for that role to translate errors between levels (this often
is needed in other such isolation-layer roles), since most (possibly all)
of the errors become language level compile time errors.

On Mon, Nov 14, 2016 at 5:08 PM, Aaron Sherman  wrote:

> I guess I wasn't clear in what I was asking:
>
> What, exactly, was it that NQP was doing? What were the inputs and what
> was the behavior that you observed? So far, all I have to go on is one
> example that you feel is not illustrating the broken behavior of NQP that
> you want to work around with a change to the way Callable and calling work.
> I'm not suggesting that the latter is bad, but it seems to be a patch
> around a problem in the former...
>
>
>
>
> Aaron Sherman, M.:
> P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
> Toolsmith, developer, gamer and life-long student.
>
>
> On Mon, Nov 14, 2016 at 4:32 PM, Brandon Allbery 
> wrote:
>
>>
>> On Mon, Nov 14, 2016 at 4:28 PM, Aaron Sherman  wrote:
>>
>>> So, you said that the problem arises because NQP does something
>>> non-obvious that results in this error. Can you be clear on what that
>>> non-obvious behavior is? It sounds to me like you're addressing a symptom
>>> of a systemic issue.
>>
>>
>> That's pretty much the definition of LTA. The programmer did something
>> that on some level involves a call (in the simple example it was explicit,
>> but there are some implicit ones in the language), and got a runtime error
>> referencing an internal name instead of something preferably compile time
>> related to what they wrote. The fix for this is to abstract it into a role
>> that describes "calling"/"invoking" instead of having a CALL-ME that the
>> user didn't (and probably shouldn't) define suddenly pop up out of nowhere.
>> That isn't the part that's difficult, aside from "so why wasn't it done
>> that way to begin with?".
>>
>> --
>> brandon s allbery kf8nh   sine nomine
>> associates
>> allber...@gmail.com
>> ballb...@sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>
>


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

Re: CALL-ME vs. Callable

[Aaron Sherman]

I guess I wasn't clear in what I was asking:

What, exactly, was it that NQP was doing? What were the inputs and what was
the behavior that you observed? So far, all I have to go on is one example
that you feel is not illustrating the broken behavior of NQP that you want
to work around with a change to the way Callable and calling work. I'm not
suggesting that the latter is bad, but it seems to be a patch around a
problem in the former...




Aaron Sherman, M.:
P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
Toolsmith, developer, gamer and life-long student.


On Mon, Nov 14, 2016 at 4:32 PM, Brandon Allbery 
wrote:

>
> On Mon, Nov 14, 2016 at 4:28 PM, Aaron Sherman  wrote:
>
>> So, you said that the problem arises because NQP does something
>> non-obvious that results in this error. Can you be clear on what that
>> non-obvious behavior is? It sounds to me like you're addressing a symptom
>> of a systemic issue.
>
>
> That's pretty much the definition of LTA. The programmer did something
> that on some level involves a call (in the simple example it was explicit,
> but there are some implicit ones in the language), and got a runtime error
> referencing an internal name instead of something preferably compile time
> related to what they wrote. The fix for this is to abstract it into a role
> that describes "calling"/"invoking" instead of having a CALL-ME that the
> user didn't (and probably shouldn't) define suddenly pop up out of nowhere.
> That isn't the part that's difficult, aside from "so why wasn't it done
> that way to begin with?".
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>

Re: CALL-ME vs. Callable

[Brandon Allbery]

On Mon, Nov 14, 2016 at 5:00 PM, Jon Lang  wrote:

> So what is the assuming method, and why is it in a callable role? What was
> the logic behind that decision?


It's perfectly sensible: it's how you implement partial application (which
as sadly usual is mis-called "currying"). (foo) is a
callable (and a Callable; note however that some-callable is not
necessarily a Callable!) which, when invoked, invokes
some-callable(foo, <*parameters
to invocation here*>).


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

Re: CALL-ME vs. Callable

[Jon Lang]

So what is the assuming method, and why is it in a callable role? What was
the logic behind that decision?

On Nov 14, 2016 1:38 PM, "Brandon Allbery"  wrote:

> This should probably have been cc-d to the list.
>
> Callable claims to be the thing we want. What it actually is, is a mix-in
> that adds the assuming method. I am not sure these can be conflated.
>
> Note that the current docs actually do claim it is what I want. This is
> because I first brought this up in IRC while the documentation for
> Callable was being written, and it got modified to match my then current
> musings because nobody who actually works on the spec was around. I had in
> fact specified that this was a "would be nice" but that I wasn't sure if it
> would actually work; I have since concluded that it likely won't, and needs
> to be a distinct role. Which is part of why I brought this up: the current
> doc does not match what currently happens, and may not actually be
> implementable without breaking the spec (that is, 6.d would have a
> fundamental conflict with 6.c over the meaning of Callable).
>
> On Mon, Nov 14, 2016 at 4:30 PM, Jon Lang  wrote:
>
>> Okay, let's go with that. What does Callable do, and why is it called
>> that?
>>
>> On Nov 14, 2016 1:09 PM, "Brandon Allbery"  wrote:
>>
>>>
>>> On Mon, Nov 14, 2016 at 3:42 PM, Aaron Sherman  wrote:
>>>
 I do think, though that if the concern is really with "the 4 cases
 when nqp hauls a CALL-ME out of its bowels" then that's what should be
 addressed...

>>>
>>> The main addressing of that is some kind of role to abstract it
>>> properly. I just think the current situation is bad and even if we come up
>>> with a name for the new role, it's still going to be confusing ("ok, why do
>>> we have both Callable and Invokable? ...uh wait, Callable means *what*
>>> exactly?").
>>>
>>>
>>> --
>>> brandon s allbery kf8nh   sine nomine
>>> associates
>>> allber...@gmail.com
>>> ballb...@sinenomine.net
>>> unix, openafs, kerberos, infrastructure, xmonad
>>> http://sinenomine.net
>>>
>>
>
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>

Re: CALL-ME vs. Callable

[Brandon Allbery]

This should probably have been cc-d to the list.

Callable claims to be the thing we want. What it actually is, is a mix-in
that adds the assuming method. I am not sure these can be conflated.

Note that the current docs actually do claim it is what I want. This is
because I first brought this up in IRC while the documentation for Callable
was being written, and it got modified to match my then current musings
because nobody who actually works on the spec was around. I had in fact
specified that this was a "would be nice" but that I wasn't sure if it
would actually work; I have since concluded that it likely won't, and needs
to be a distinct role. Which is part of why I brought this up: the current
doc does not match what currently happens, and may not actually be
implementable without breaking the spec (that is, 6.d would have a
fundamental conflict with 6.c over the meaning of Callable).

On Mon, Nov 14, 2016 at 4:30 PM, Jon Lang  wrote:

> Okay, let's go with that. What does Callable do, and why is it called that?
>
> On Nov 14, 2016 1:09 PM, "Brandon Allbery"  wrote:
>
>>
>> On Mon, Nov 14, 2016 at 3:42 PM, Aaron Sherman  wrote:
>>
>>> I do think, though that if the concern is really with "the 4 cases when
>>> nqp hauls a CALL-ME out of its bowels" then that's what should be
>>> addressed...
>>>
>>
>> The main addressing of that is some kind of role to abstract it properly.
>> I just think the current situation is bad and even if we come up with a
>> name for the new role, it's still going to be confusing ("ok, why do we
>> have both Callable and Invokable? ...uh wait, Callable means *what*
>> exactly?").
>>
>>
>> --
>> brandon s allbery kf8nh   sine nomine
>> associates
>> allber...@gmail.com
>> ballb...@sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>


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

Re: CALL-ME vs. Callable

[Brandon Allbery]

On Mon, Nov 14, 2016 at 4:28 PM, Aaron Sherman  wrote:

> So, you said that the problem arises because NQP does something
> non-obvious that results in this error. Can you be clear on what that
> non-obvious behavior is? It sounds to me like you're addressing a symptom
> of a systemic issue.


That's pretty much the definition of LTA. The programmer did something that
on some level involves a call (in the simple example it was explicit, but
there are some implicit ones in the language), and got a runtime error
referencing an internal name instead of something preferably compile time
related to what they wrote. The fix for this is to abstract it into a role
that describes "calling"/"invoking" instead of having a CALL-ME that the
user didn't (and probably shouldn't) define suddenly pop up out of nowhere.
That isn't the part that's difficult, aside from "so why wasn't it done
that way to begin with?".

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

Re: CALL-ME vs. Callable

[Aaron Sherman]

So, you said that the problem arises because NQP does something non-obvious
that results in this error. Can you be clear on what that non-obvious
behavior is? It sounds to me like you're addressing a symptom of a systemic
issue.


Aaron Sherman, M.:
P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
Toolsmith, developer, gamer and life-long student.


On Mon, Nov 14, 2016 at 4:08 PM, Brandon Allbery 
wrote:

>
> On Mon, Nov 14, 2016 at 3:42 PM, Aaron Sherman  wrote:
>
>> I do think, though that if the concern is really with "the 4 cases when
>> nqp hauls a CALL-ME out of its bowels" then that's what should be
>> addressed...
>>
>
> The main addressing of that is some kind of role to abstract it properly.
> I just think the current situation is bad and even if we come up with a
> name for the new role, it's still going to be confusing ("ok, why do we
> have both Callable and Invokable? ...uh wait, Callable means *what*
> exactly?").
>
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>

Re: CALL-ME vs. Callable

[Aaron Sherman]

Fair points, all.

I do think, though that if the concern is really with "the 4 cases when nqp
hauls a CALL-ME out of its bowels" then that's what should be addressed...



Aaron Sherman, M.:
P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
Toolsmith, developer, gamer and life-long student.


On Mon, Nov 14, 2016 at 3:22 PM, Brandon Allbery 
wrote:

> Also...
>
> On Mon, Nov 14, 2016 at 3:06 PM, Aaron Sherman  wrote:
>
>> Role-based testing seems very perl6ish. I'd suggest the role name be
>> "Invocable" with much the sort of signature as you've described.
>
>
> If it's Invokable then the method should probably be INVOKE. It still
> leaves the question of why Callable appears to be the only role named
> after what it applies to instead of what it provides.
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>

Re: CALL-ME vs. Callable

[Brandon Allbery]

Also...

On Mon, Nov 14, 2016 at 3:06 PM, Aaron Sherman  wrote:

> Role-based testing seems very perl6ish. I'd suggest the role name be
> "Invocable" with much the sort of signature as you've described.


If it's Invokable then the method should probably be INVOKE. It still
leaves the question of why Callable appears to be the only role named after
what it applies to instead of what it provides.

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

Re: fixing infinities and ranges etc

[Darren Duncan]

On 2016-10-30 5:45 AM, yary wrote:

I'm not sure I entirely understand the proposal- does it change Inf aka ∞ ?


Part of the issue I think is that the existing "Inf" aka "∞" don't seem to be 
very clearly defined.


What I could find so far, at least with respect to Ranges, is that they are just 
syntactic alternatives to the Whatever *.


They don't seem to be actual typed values that one can say use as declared types 
for things.



Otherwise I like it, and prefer the X::NegInf and X::PosInf,spellings as being
easy-to-understand & a good Huffman-encoding.


Ok.


Before/AfterEverything are also easy to understand, and would be as natural to
use for sorting strings, eg. for saying if a database NULL should go before the
empty string or after everything else. On the other hand, if I'doing something
with tangents and handling pi/2, I'd rather be thinking about PosInf as my
exception and not AfterEverything.


So, the main thing that I think should exist is a generic 
before/after-everything concept so that it can be used to indicate that generic 
intervals are unbounded at either end and that generic 'cmp' etc are 
automatically defined for every other type and them and use as identity values 
for min/max.


At the same time, I think some people would want to distinguish between these 
and a mathematical concept of infinity in a similar manner that people 
distinguish orderable and ordered and ordinal etc.


What I mean by the latter is, "ordered" and "ordinal" have rather precise 
meanings in set theory or mathematics etc, meanings that don't apply to a lot of 
data types we tend to sort on.  For example, ordered/ordinal strictly speaking 
wouldn't apply to character strings and they may not apply consistently to the 
general case of rational numbers and so on; for some types we just want to be 
able to sort them deterministically but the actual sort order might not be 
meaningful within the domain.  So I made up the term "orderable" to refer to 
what generic "cmp" or SQL "order by" etc do.


The before/after-everything singleton are meant specifically to apply to this 
"orderable" concept.


So, having that, the question is whether we want to have distinct infinity 
concepts for numbers from those, and I suspect we might.  In maths we have 
directional infinities on a line, but there's also the concept of something 
being infinite that is not directional such as an unbounded volume, and there's 
also countable vs uncountable infinities etc.  We may not want to imply any of 
those with our before/after-everything concept which is meant to serve a 
different purpose.



X::BE and X::AE are too short to use outside of this discussion, especially as
"BE" is the common verb "be."


Maybe X::OBE and X::OAE for "ordered before/after everything"?

Anyway, this part is bike-shedding, my main point is that the singletons simply 
exist and what their properties are.



Before/AfterEverything ... would be as natural to
use for sorting strings, eg. for saying if a database NULL should go before the
empty string or after everything else.


So, now this brings up a different thing.

A Perl 6 analogy to a SQL Null would ALSO be a Failure singleton type, for 
example X::NoReason, basically it means that we don't have a normal value of the 
domain here AND we are giving absolutely no explanation for why the normal value 
is missing.  A SQL Null in general means means "we don't have a normal value and 
we aren't saying why", it does NOT mean "not applicable" or "unknown" or 
"missing" or "not matched" or anything like that, it doesn't even say which of 
those it is.


As far as I could tell the Perl 6 Nil singleton had this X::NoReason meaning, 
but if it actually doesn't, then we should have a new X::NoReason to be more 
explicit about that.  This would mean that a Perl 6 Nil actually IS giving a 
reason why the normal value is absent.


As a final note today, I will mention that the subject of this email thread is 
relevant to this thing that I'm working on, a DBI for Perl 6 with a PSGI/Plack 
inspired design, meaning a no-mandatory-shared-code database interface:


https://github.com/muldis/Muldis-DBI-Duck-Coupling-Perl6/blob/master/lib/Muldis/DBI/Duck_Coupling/API.pod

-- Darren Duncan

Re: fixing infinities and ranges etc

[yary]

I'm not sure I entirely understand the proposal- does it change Inf aka ∞ ?

Otherwise I like it, and prefer the X::NegInf and X::PosInf,spellings as
being easy-to-understand & a good Huffman-encoding.

Before/AfterEverything are also easy to understand, and would be as natural
to use for sorting strings, eg. for saying if a database NULL should go
before the empty string or after everything else. On the other hand, if
I'doing something with tangents and handling pi/2, I'd rather be thinking
about PosInf as my exception and not AfterEverything.

X::BE and X::AE are too short to use outside of this discussion, especially
as "BE" is the common verb "be."

Re: Documentation for error messages

[Wenzel P. P. Peppmeyer]

On Mon, 24 Oct 2016, Parrot Raiser wrote:


Where's the best current description of error messages from file
"open" commands, and how to control them?


`git grep 'does X::IO'` is your best bet right now because some
X::IO-exceptions are not documented yet.

Re: Is this a bug?

[Aaron Sherman]

Thank you. Silly me, thinking "this is so simple I don't need to run it
through the command-line to test it." :-)

Anway, yeah,

 say $_ for reverse lines



Aaron Sherman, M.:
P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
Toolsmith, developer, gamer and life-long student.


On Mon, Sep 19, 2016 at 10:10 AM, Timo Paulssen  wrote:

> On 19/09/16 16:02, Aaron Sherman wrote:
> > I'm guessing that what you meant was "say as a function was what I >
> meant to use there." In which case: > > say for reverse lines > > or > >
> for reverse lines { say } > > These are both valid ways of asking for each
> element of the iterable > thing returned from lines to be printed with a
> newline.
> Watch out, this needs to read say $_ otherwise you would get an error
> message:
>
> Unsupported use of bare "say"; in Perl 6 please use .say if you meant $_,
> or use an explicit invocant or argument, or use  to refer to the
> function as a noun
>
>

Re: Is this a bug?

[Parrot Raiser]

It may make it clearer if I explain the broader objective. I'm trying
to learn P6 thoroughly by developing training courses to teach it from
scratch. (Fans of Gerald Weinberg may recognise the idea.) Obviously,
while doing so, I want to explore pathological cases, both to clarify
the concepts and to anticipate the mistakes that students might make.
Sometimes, it's necessary to do so to resolve ambiguities in whatever
sources are available.

The language is far too deep and complex to absorb in one pass, and
contains a great deal which is of interest to advanced system software
developers, but not to someone who just wants to do some simple
processing or file manipulation. My aim is to develop a series of
successively deeper courses, each of which will be complete within
itself. The first level is procedural. O-O is the next.

Topics should proceed logically from the basics, each building on the
previous, without having to drag in extraneous topics or diversions.
(Examples should not require forward references or bouncing around in
the text.) That's why I don't want to introduce .say at this stage, if
I can help it.

On 9/18/16, Trey Harris  wrote:
> On Sun, Sep 18, 2016 at 16:49 Parrot Raiser <1parr...@gmail.com> wrote:
>
> say { $_ } was the correct thing to use there. (I'm trying to avoid
>> any mention of O-O for the moment.)
>>
> “Trying to avoid any mention of O-O” seems like a Perl 6 obfuscation or
> golf constraint, not a desirable development or learning goal. Perl 6
> doesn’t *force* you to write programs in an object-oriented style; you can
> do it in functional or procedural or whatever style suits you. But you’re
> going to have a bad time if you try to deny Perl 6’s fully OO nature. This
> is in stark contrast to Perl 5, where OO was bolted on, and you could say
> that the non-OO core was more “real” than the object-oriented sugar found
> in modules you had to use.
>
> Writing something like say($_) for reverse lines — which is what I think is
> closest to what you wanted — isn’t any more or less “object-oriented” than
> the more idiomatic .say for reverse lines;. In Perl 5, some rather
> byzantine rules governed the use of the implicit $_; almost all of the
> convenience afforded by those rules can be gained through the use of
> topicalized objects, so the byzantine rules are gone — but the convenience
> is gone too unless you’re willing to use the topic in the .foo style.
>
> I think perhaps you see a dot, and dot signifies OO, so the .say... version
> might *look* more OO than the say(... version in some sense, but that’s
> pretty much cosmetic. You’re *using* some objects by interacting with the
> Perl 6 core either way. It’s your choice not to write your logic in an OO
> style, but you can’t prevent OO from happening during execution.
>
> (This really isn’t some half-hearted attempt to force you into OO through
> the backdoor; you really can skip OO for all *your* logic. You just can’t
> pretend you’re not using an object-oriented language when you have to touch
> code you’re not in control of, whether an OO library or the Perl 6 core.
> But pretty much the entirety of what you need to know about OO if you
> choose to do that is various syntax and some desiderata about the calling
> semantics.)
>
> say {} was a "what happens if I do this" exercise.
>>
>> What is this  -> ;; $_? is raw { #`(Block|170303864) … } output?
>>
>> On 9/18/16, Brent Laabs  wrote:
>> > Remember you can call a block with parentheses:
>> >
>> >> say { 11 + 31 };
>> > -> ;; $_? is raw { #`(Block|140268472711224) ... }
>> >> say { 11 + 31 }();
>> > 42
>> >
>> >
>> > On Sun, Sep 18, 2016 at 12:58 PM, Elizabeth Mattijsen 
>> > wrote:
>> >
>> >> I think you want:
>> >>
>> >>   .say for reverse lines;
>> >>
>> >> not sure what you are trying to achieve otherwise, but:
>> >>
>> >>say { }
>> >>
>> >> producing something like
>> >>
>> >>-> ;; $_? is raw { #`(Block|170303864) … }
>> >>
>> >> feels entirely correct to me.   :-)
>> >>
>> >>
>> >> Liz
>> >>
>> >> > On 18 Sep 2016, at 21:52, Parrot Raiser <1parr...@gmail.com> wrote:
>> >> >
>> >> > This code:
>> >> > 1 #! /home/guru/bin/perl6
>> >> > 2
>> >> > 3 # Ask for some lines and output them in reverse
>> >> > 4 # Work out the appropriate EOF symbol for the OS
>> >> > 5
>> >> > 6 my $EOF = "CTRL-" ~ ($*DISTRO.is-win ?? "Z" !! "D");
>> >> > 7
>> >> > 8 say "Please enter some lines and end them with $EOF";
>> >> > 9
>> >> > 10 say { for reverse lines() {} };
>> >> > 11
>> >> > 12 # End
>> >> > produces this:
>> >> > Please enter some lines and end them with CTRL-D# obviously from
>> >> line 8
>> >> > -> ;; $_? is raw { #`(Block|170303864) ... }#
>> >> > but
>> >> this?
>> >>
>> >>
>> >
>>
> ​
>

Re: Is this a bug?

[Timo Paulssen]

On 19/09/16 16:02, Aaron Sherman wrote:
> I'm guessing that what you meant was "say as a function was what I > meant to 
> use there." In which case: > > say for reverse lines > > or
> > for reverse lines { say } > > These are both valid ways of asking
for each element of the iterable > thing returned from lines to be
printed with a newline.
Watch out, this needs to read say $_ otherwise you would get an error
message:

Unsupported use of bare "say"; in Perl 6 please use .say if you meant
$_, or use an explicit invocant or argument, or use  to refer to the
function as a noun

Re: This seems to be wrong

[Timo Paulssen]

On 19/09/16 15:56, Aaron Sherman wrote:> You can also use map, but it's
slightly clunkier: > > "for @inputs.map: .Int -> $i { ... }"
This also needs to have "*.Int" or "{ .Int }" otherwise you'll pass
$_.Int as the argument to map rather than telling map to call .Int on
things.

Re: Is this a bug?

[Aaron Sherman]

I'm guessing that what you meant was "say as a function was what I meant to
use there." In which case:

say for reverse lines

or

for reverse lines { say }

These are both valid ways of asking for each element of the iterable thing
returned from lines to be printed with a newline.

But remember that any {} around code creates a Block in Perl 6, and a Block
is a first-class object. If you ask say to print a Block, it will quite
happily try to do that.




Aaron Sherman, M.:
P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
Toolsmith, developer, gamer and life-long student.


On Sun, Sep 18, 2016 at 4:49 PM, Parrot Raiser <1parr...@gmail.com> wrote:

> say { $_ } was the correct thing to use there. (I'm trying to avoid
> any mention of O-O for the moment.)
> say {} was a "what happens if I do this" exercise.
>
> What is this  -> ;; $_? is raw { #`(Block|170303864) … } output?
>
> On 9/18/16, Brent Laabs  wrote:
> > Remember you can call a block with parentheses:
> >
> >> say { 11 + 31 };
> > -> ;; $_? is raw { #`(Block|140268472711224) ... }
> >> say { 11 + 31 }();
> > 42
> >
> >
> > On Sun, Sep 18, 2016 at 12:58 PM, Elizabeth Mattijsen 
> > wrote:
> >
> >> I think you want:
> >>
> >>   .say for reverse lines;
> >>
> >> not sure what you are trying to achieve otherwise, but:
> >>
> >>say { }
> >>
> >> producing something like
> >>
> >>-> ;; $_? is raw { #`(Block|170303864) … }
> >>
> >> feels entirely correct to me.   :-)
> >>
> >>
> >> Liz
> >>
> >> > On 18 Sep 2016, at 21:52, Parrot Raiser <1parr...@gmail.com> wrote:
> >> >
> >> > This code:
> >> > 1 #! /home/guru/bin/perl6
> >> > 2
> >> > 3 # Ask for some lines and output them in reverse
> >> > 4 # Work out the appropriate EOF symbol for the OS
> >> > 5
> >> > 6 my $EOF = "CTRL-" ~ ($*DISTRO.is-win ?? "Z" !! "D");
> >> > 7
> >> > 8 say "Please enter some lines and end them with $EOF";
> >> > 9
> >> > 10 say { for reverse lines() {} };
> >> > 11
> >> > 12 # End
> >> > produces this:
> >> > Please enter some lines and end them with CTRL-D# obviously from
> >> line 8
> >> > -> ;; $_? is raw { #`(Block|170303864) ... }# but
> >> this?
> >>
> >>
> >
>

Re: This seems to be wrong

[Aaron Sherman]

"for @inputs.map( .prefix:<+> ) {...}"

That's spelled:

"for @inputs>>.Int -> $i { ... }"

You can also use map, but it's slightly clunkier:

"for @inputs.map: .Int -> $i { ... }"



Aaron Sherman, M.:
P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
Toolsmith, developer, gamer and life-long student.


On Sun, Sep 18, 2016 at 6:06 PM, Trey Harris  wrote:

> Why does this:
>
> for @inputs.map( .prefix:<+> ) { ... }
>
> Not work? It results inMethod 'prefix:<+>' not found for invocant of
> class 'Any', but the docs
>  say it is defined as
> a multi on Any….
>
> Trey
> ​
>
> On Sun, Sep 18, 2016 at 4:37 PM Brandon Allbery 
> wrote:
>
>> On Sun, Sep 18, 2016 at 4:31 PM, Parrot Raiser <1parr...@gmail.com>
>> wrote:
>>
>>> but seems to have a problem with larger numbers:
>>>
>>> 7
>>> 3
>>> 21  <- This
>>> 2
>>> 1
>>> 0
>>> 4
>>> bamm-bamm
>>> barney
>>> (Any)  <--- Produces this
>>> betty
>>> fred
>>> 0 out of range 1..7
>>> dino
>>>
>>
>> [18 20:35]  m: say so "21" ~~ 1..7
>> [18 20:35]  rakudo-moar 34f950: OUTPUT«True␤
>> [18 20:35]  »
>>
>> It came from lines(), it is a Str. Numify it first.
>>
>> --
>> brandon s allbery kf8nh   sine nomine
>> associates
>> allber...@gmail.com
>> ballb...@sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>

Re: This seems to be wrong

[Trey Harris]

D’oh! I’m blind.

But I see there’s a multi method Str defined on Any, and you can’t do
@inputs.map( .Str ), either (Use of uninitialized value $_ of type Any in
string context). Why not? (There’s no multi method Num on Any, even though
the docs about Cool  seem to imply there
should be…)
​

On Sun, Sep 18, 2016 at 6:15 PM Brandon Allbery  wrote:

>
> On Sun, Sep 18, 2016 at 6:06 PM, Trey Harris  wrote:
>
>> Not work? It results inMethod 'prefix:<+>' not found for invocant of
>> class 'Any', but the docs
>> 
>>
>> say it is defined as a multi on Any….
>>
>>
> No, they say it's a multi sub, not a multi method on Any. And the prefix:
> syntax doesn't seem to work directly with the quick workaround for that, so
> it ends up being
>
> for @inputs.map({ .:<+> }) { ... }
>
>
>
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>

Re: This seems to be wrong

[Trey Harris]

On Sun, Sep 18, 2016 at 6:30 PM Brandon Allbery allber...@gmail.com
 wrote:


> On Sun, Sep 18, 2016 at 6:29 PM, Trey Harris  wrote:
>
>> But I see there’s a multi method Str defined on Any, and you can’t do
>> @inputs.map( .Str ), either (Use of uninitialized value $_ of type Any
>> in string context). Why not? (There’s no multi method Num on Any, even
>> though the docs about Cool 
>>
>> seem to imply there should be…)
>>
>>
> Same reason I had to wrap it in a Block --- it's not recognizing .Str as a
> closure, it's running it immediately. Perhaps you wanted *.Str?
>
Right, got it.

Does not being defined on Any explain why the error for @input.map( .Str )
is different (Use of uninitialized value $_ of type Any in string context)
than the error for @input.map( .Num ) (Method 'Num' not found for invocant
of class 'Any'), but both*.Str and *.Num work in the .map?


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

Re: This seems to be wrong

[Brandon Allbery]

On Sun, Sep 18, 2016 at 6:36 PM, Trey Harris  wrote:

> Does not being defined on Any explain why the error for @input.map( .Str )
> is different (Use of uninitialized value $_ of type Any in string context)
> than the error for @input.map( .Num ) (Method 'Num' not found for
> invocant of class 'Any'), but both*.Str and *.Num work in the .map?
>
Yes. Without the *, it's doing $_.Str or $_.Num when $_ is the one
*outside* the map call, which has no current value (and so is (Any)); in
the Str case it is invoking Any.Str and failing on the undefined value, in
the Num case it can't find the method for Any. With the *, it's a closure
and applies to the $_ current for each iteration of map; the invocant is a
defined Str.



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

Re: Is this a bug?

[Trey Harris]

On Sun, Sep 18, 2016 at 16:49 Parrot Raiser <1parr...@gmail.com> wrote:

say { $_ } was the correct thing to use there. (I'm trying to avoid
> any mention of O-O for the moment.)
>
“Trying to avoid any mention of O-O” seems like a Perl 6 obfuscation or
golf constraint, not a desirable development or learning goal. Perl 6
doesn’t *force* you to write programs in an object-oriented style; you can
do it in functional or procedural or whatever style suits you. But you’re
going to have a bad time if you try to deny Perl 6’s fully OO nature. This
is in stark contrast to Perl 5, where OO was bolted on, and you could say
that the non-OO core was more “real” than the object-oriented sugar found
in modules you had to use.

Writing something like say($_) for reverse lines — which is what I think is
closest to what you wanted — isn’t any more or less “object-oriented” than
the more idiomatic .say for reverse lines;. In Perl 5, some rather
byzantine rules governed the use of the implicit $_; almost all of the
convenience afforded by those rules can be gained through the use of
topicalized objects, so the byzantine rules are gone — but the convenience
is gone too unless you’re willing to use the topic in the .foo style.

I think perhaps you see a dot, and dot signifies OO, so the .say... version
might *look* more OO than the say(... version in some sense, but that’s
pretty much cosmetic. You’re *using* some objects by interacting with the
Perl 6 core either way. It’s your choice not to write your logic in an OO
style, but you can’t prevent OO from happening during execution.

(This really isn’t some half-hearted attempt to force you into OO through
the backdoor; you really can skip OO for all *your* logic. You just can’t
pretend you’re not using an object-oriented language when you have to touch
code you’re not in control of, whether an OO library or the Perl 6 core.
But pretty much the entirety of what you need to know about OO if you
choose to do that is various syntax and some desiderata about the calling
semantics.)

say {} was a "what happens if I do this" exercise.
>
> What is this  -> ;; $_? is raw { #`(Block|170303864) … } output?
>
> On 9/18/16, Brent Laabs  wrote:
> > Remember you can call a block with parentheses:
> >
> >> say { 11 + 31 };
> > -> ;; $_? is raw { #`(Block|140268472711224) ... }
> >> say { 11 + 31 }();
> > 42
> >
> >
> > On Sun, Sep 18, 2016 at 12:58 PM, Elizabeth Mattijsen 
> > wrote:
> >
> >> I think you want:
> >>
> >>   .say for reverse lines;
> >>
> >> not sure what you are trying to achieve otherwise, but:
> >>
> >>say { }
> >>
> >> producing something like
> >>
> >>-> ;; $_? is raw { #`(Block|170303864) … }
> >>
> >> feels entirely correct to me.   :-)
> >>
> >>
> >> Liz
> >>
> >> > On 18 Sep 2016, at 21:52, Parrot Raiser <1parr...@gmail.com> wrote:
> >> >
> >> > This code:
> >> > 1 #! /home/guru/bin/perl6
> >> > 2
> >> > 3 # Ask for some lines and output them in reverse
> >> > 4 # Work out the appropriate EOF symbol for the OS
> >> > 5
> >> > 6 my $EOF = "CTRL-" ~ ($*DISTRO.is-win ?? "Z" !! "D");
> >> > 7
> >> > 8 say "Please enter some lines and end them with $EOF";
> >> > 9
> >> > 10 say { for reverse lines() {} };
> >> > 11
> >> > 12 # End
> >> > produces this:
> >> > Please enter some lines and end them with CTRL-D# obviously from
> >> line 8
> >> > -> ;; $_? is raw { #`(Block|170303864) ... }# but
> >> this?
> >>
> >>
> >
>
​

Re: This seems to be wrong

[Brandon Allbery]

On Sun, Sep 18, 2016 at 6:29 PM, Trey Harris  wrote:

> But I see there’s a multi method Str defined on Any, and you can’t do
> @inputs.map( .Str ), either (Use of uninitialized value $_ of type Any in
> string context). Why not? (There’s no multi method Num on Any, even
> though the docs about Cool 
>
> seem to imply there should be…)
>
>
Same reason I had to wrap it in a Block --- it's not recognizing .Str as a
closure, it's running it immediately. Perhaps you wanted *.Str?


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

Re: This seems to be wrong

[Brandon Allbery]

On Sun, Sep 18, 2016 at 6:15 PM, Brandon Allbery 
wrote:

> for @inputs.map({ .:<+> }) { ... }


Which means the shorter way is:

for @inputs.map(+*) { ... }


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

Re: This seems to be wrong

[Brandon Allbery]

On Sun, Sep 18, 2016 at 6:06 PM, Trey Harris  wrote:

> Not work? It results inMethod 'prefix:<+>' not found for invocant of
> class 'Any', but the docs
> 
>
> say it is defined as a multi on Any….
>
>
No, they say it's a multi sub, not a multi method on Any. And the prefix:
syntax doesn't seem to work directly with the quick workaround for that, so
it ends up being

for @inputs.map({ .:<+> }) { ... }




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

Re: Is this a bug?

[Brandon Allbery]

On Sun, Sep 18, 2016 at 4:49 PM, Parrot Raiser <1parr...@gmail.com> wrote:

> What is this  -> ;; $_? is raw { #`(Block|170303864) … } output?


It's the gist of a Block, which is what you asked for when you did a `say`
on an executable block.
Why do you believe `say { $_ }` is the right thing there? What were you
expecting it to do?

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

Re: Is this a bug?

[Elizabeth Mattijsen]

It is the .perl representation of a Block.

> On 18 Sep 2016, at 22:49, Parrot Raiser <1parr...@gmail.com> wrote:
> 
> say { $_ } was the correct thing to use there. (I'm trying to avoid
> any mention of O-O for the moment.)
> say {} was a "what happens if I do this" exercise.
> 
> What is this  -> ;; $_? is raw { #`(Block|170303864) … } output?
> 
> On 9/18/16, Brent Laabs  wrote:
>> Remember you can call a block with parentheses:
>> 
>>> say { 11 + 31 };
>> -> ;; $_? is raw { #`(Block|140268472711224) ... }
>>> say { 11 + 31 }();
>> 42
>> 
>> 
>> On Sun, Sep 18, 2016 at 12:58 PM, Elizabeth Mattijsen 
>> wrote:
>> 
>>> I think you want:
>>> 
>>>  .say for reverse lines;
>>> 
>>> not sure what you are trying to achieve otherwise, but:
>>> 
>>>   say { }
>>> 
>>> producing something like
>>> 
>>>   -> ;; $_? is raw { #`(Block|170303864) … }
>>> 
>>> feels entirely correct to me.   :-)
>>> 
>>> 
>>> Liz
>>> 
 On 18 Sep 2016, at 21:52, Parrot Raiser <1parr...@gmail.com> wrote:
 
 This code:
 1 #! /home/guru/bin/perl6
 2
 3 # Ask for some lines and output them in reverse
 4 # Work out the appropriate EOF symbol for the OS
 5
 6 my $EOF = "CTRL-" ~ ($*DISTRO.is-win ?? "Z" !! "D");
 7
 8 say "Please enter some lines and end them with $EOF";
 9
 10 say { for reverse lines() {} };
 11
 12 # End
 produces this:
 Please enter some lines and end them with CTRL-D# obviously from
>>> line 8
 -> ;; $_? is raw { #`(Block|170303864) ... }# but
>>> this?
>>> 
>>> 
>> 

Re: Is this a bug?

[Brent Laabs]

Remember you can call a block with parentheses:

> say { 11 + 31 };
-> ;; $_? is raw { #`(Block|140268472711224) ... }
> say { 11 + 31 }();
42


On Sun, Sep 18, 2016 at 12:58 PM, Elizabeth Mattijsen 
wrote:

> I think you want:
>
>   .say for reverse lines;
>
> not sure what you are trying to achieve otherwise, but:
>
>say { }
>
> producing something like
>
>-> ;; $_? is raw { #`(Block|170303864) … }
>
> feels entirely correct to me.   :-)
>
>
> Liz
>
> > On 18 Sep 2016, at 21:52, Parrot Raiser <1parr...@gmail.com> wrote:
> >
> > This code:
> > 1 #! /home/guru/bin/perl6
> > 2
> > 3 # Ask for some lines and output them in reverse
> > 4 # Work out the appropriate EOF symbol for the OS
> > 5
> > 6 my $EOF = "CTRL-" ~ ($*DISTRO.is-win ?? "Z" !! "D");
> > 7
> > 8 say "Please enter some lines and end them with $EOF";
> > 9
> > 10 say { for reverse lines() {} };
> > 11
> > 12 # End
> > produces this:
> > Please enter some lines and end them with CTRL-D# obviously from
> line 8
> > -> ;; $_? is raw { #`(Block|170303864) ... }# but
> this?
>
>

Re: This seems to be wrong

[Brandon Allbery]

On Sun, Sep 18, 2016 at 4:31 PM, Parrot Raiser <1parr...@gmail.com> wrote:

> but seems to have a problem with larger numbers:
>
> 7
> 3
> 21  <- This
> 2
> 1
> 0
> 4
> bamm-bamm
> barney
> (Any)  <--- Produces this
> betty
> fred
> 0 out of range 1..7
> dino
>

[18 20:35]  m: say so "21" ~~ 1..7
[18 20:35]  rakudo-moar 34f950: OUTPUT«True␤
[18 20:35]  »

It came from lines(), it is a Str. Numify it first.

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

Re: Is this a bug?

[Elizabeth Mattijsen]

I think you want:

  .say for reverse lines;

not sure what you are trying to achieve otherwise, but:

   say { }

producing something like

   -> ;; $_? is raw { #`(Block|170303864) … }

feels entirely correct to me.   :-)


Liz

> On 18 Sep 2016, at 21:52, Parrot Raiser <1parr...@gmail.com> wrote:
> 
> This code:
> 1 #! /home/guru/bin/perl6
> 2
> 3 # Ask for some lines and output them in reverse
> 4 # Work out the appropriate EOF symbol for the OS
> 5
> 6 my $EOF = "CTRL-" ~ ($*DISTRO.is-win ?? "Z" !! "D");
> 7
> 8 say "Please enter some lines and end them with $EOF";
> 9
> 10 say { for reverse lines() {} };
> 11
> 12 # End
> produces this:
> Please enter some lines and end them with CTRL-D# obviously from line 8
> -> ;; $_? is raw { #`(Block|170303864) ... }# but this?

Re: Help mechanism in REPL?

[Elizabeth Mattijsen]

FWIW, the .WHY is a method just like any other.  What would need to be changed, 
is the behaviour of Mu.WHY (around line 60 in Mu.pm).

> On 10 Sep 2016, at 16:41, Brad Gilbert  wrote:
> 
> There was some talk in the past about having `.WHY` look up the
> descriptions in the POD6 doc ( so that we don't have to bloat Rakudo
> with that information )
> 
> On Fri, Sep 9, 2016 at 6:30 PM, Alex Elsayed  wrote:
>> On Wednesday, 7 September 2016 17:57:32 PDT Parrot Raiser wrote:
>>> This isn't a request for a feature, merely a thought experiment. We're
>>> still in the phase where it's more important to ensure that existing
>>> features work properly than add new ones.
>>> 
>>> How difficult would it be to include a mechanism within the REPL to
>>> select either documentation or an example, (possibly from the test
>>> suite), for a particular command? Selection might be by some control
>>> key combination,  cursor positioning, or an alternative to "enter" at
>>> the end of the line. The purpose would be to speed development, by
>>> enabling an inexperienced developer to look up details while testing.
>>> 
>>> Syntax errors generate messages which attempt to provide help; could
>>> this provide the basis for a "help" mechanism? Would this be useful?
>>> 
>>> Opinions?
>> 
>> Well, this sounds like a job for the meta-object protocol (specifically,
>> `.WHY`):
>> 
>> https://docs.perl6.org/language/mop#WHY
>> 
>> The simplest option for handling this in the REPL is probably to have some
>> sort of automatic handling of Pod sent to sink context, rendering it and
>> sending it to a pager. Then, the user could simply do
>> 
 Hash.WHY
>> (LET THERE BE DOCS!)
>> 
>> And there would be docs.