Re: $? and $! equivalents

2018-09-15 Thread 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

2018-09-14 Thread 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

2018-09-14 Thread 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

2018-09-10 Thread 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

2018-09-10 Thread 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

2018-09-10 Thread 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

2018-09-10 Thread 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?

2018-05-04 Thread 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

2018-03-14 Thread 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

2018-03-07 Thread 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

2018-03-04 Thread 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

2018-03-04 Thread 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

2018-03-03 Thread 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

2018-03-03 Thread 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

2018-03-03 Thread 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

2018-03-03 Thread 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

2018-03-03 Thread 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?

2018-02-20 Thread 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?

2018-02-20 Thread 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?

2018-02-20 Thread 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?

2018-02-20 Thread 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?

2018-02-16 Thread 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

2018-02-16 Thread 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?

2018-02-16 Thread 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?

2018-02-14 Thread 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?

2018-02-10 Thread 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?

2018-02-09 Thread 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?

2018-02-09 Thread 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?

2018-02-09 Thread 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?

2018-02-09 Thread 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?

2018-02-09 Thread 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?

2018-02-08 Thread 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?

2018-02-08 Thread 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?

2018-02-08 Thread 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?

2018-02-08 Thread 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?

2018-02-08 Thread 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?

2018-02-08 Thread 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?

2018-02-08 Thread 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?

2018-02-08 Thread 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

2017-07-26 Thread 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...

2017-05-15 Thread 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

2016-12-11 Thread 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

2016-12-02 Thread 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

2016-12-02 Thread 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

2016-12-02 Thread 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

2016-12-01 Thread 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

2016-11-14 Thread 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

2016-11-14 Thread 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

2016-11-14 Thread 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

2016-11-14 Thread 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

2016-11-14 Thread 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

2016-11-14 Thread 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

2016-11-14 Thread 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

2016-11-14 Thread Brandon Allbery
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, xmonadhttp://sinenomine.net


Re: CALL-ME vs. Callable

2016-11-14 Thread 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

2016-11-14 Thread 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

2016-10-30 Thread 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

2016-10-30 Thread 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

2016-10-24 Thread 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?

2016-09-19 Thread 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?

2016-09-19 Thread 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?

2016-09-19 Thread 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

2016-09-19 Thread 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?

2016-09-19 Thread 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

2016-09-19 Thread 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

2016-09-18 Thread 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

2016-09-18 Thread 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

2016-09-18 Thread 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?

2016-09-18 Thread 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

2016-09-18 Thread 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

2016-09-18 Thread Trey Harris
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

2016-09-18 Thread 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

2016-09-18 Thread 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?

2016-09-18 Thread 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?

2016-09-18 Thread 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?

2016-09-18 Thread Parrot Raiser
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?

2016-09-18 Thread 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

2016-09-18 Thread 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?

2016-09-18 Thread 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?

2016-09-10 Thread 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.



Re: Help mechanism in REPL?

2016-09-10 Thread Brad Gilbert
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.


Re: Help mechanism in REPL?

2016-09-10 Thread Rob Hoelz
On Fri, 09 Sep 2016 16:30:28 -0700
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.
> 

+1 to this; it wouldn't be too hard to have the REPL pick up on Pod types and 
render them
properly.  However, hardly any of the core types or subs have a WHY (due to 
Rakudo setting
compilation time).  There were a few ideas flying around a while ago about how 
to remedy this:

  - Generate a postamble that is optionally included in the setting that sets 
up WHY for core objects
retroactively.

  - Alter WHY's implementation slightly so that if an object has no WHY 
associated with it, there is
the option to consult a "WHY repository", which would store WHYs 
off-setting on disk or as a service
on docs.perl6.org.

I think that Parrot Raiser's original intent, in addition to object and 
function-specific help, was offering
broader categories of help from within the REPL, like Python's 
"help('keywords')".


Re: Help mechanism in REPL?

2016-09-09 Thread Alex Elsayed
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.


Re: Justification for the "reversed" instruction format

2016-09-08 Thread Trey Harris
Ah, nice, good to know my concern was unwarranted.

On Thu, Sep 8, 2016 at 3:04 PM Aaron Sherman  wrote:

> In Perl 6, we apply those constraints when you pass off the call to the
> ultimate recipient, and that's important because that recipient can have
> multiple signatures (and signatures can be added *after* you define the
> flip).
>
> For example:
>
> $ cat foo.p6
>
>
> sub flip() { -> $b, $a, |c { f($a, $b, |c) } }
>
> multi sub counter(Int $start, Int $end, :$by=1) {
> $start, *+$by ... $end
> }
> multi sub counter(Str $start, Str $end, :$by=1) {
> ($start.ord, *+$by ... $end.ord).map: {.chr}
> }
>
> my  = flip 
>
> say flip-counter  10,   2, :by(2);
> say flip-counter 'q', 'k', :by(2);
> say flip-counter 3.7,   1, :by(2);
>
> $ perl6 foo.p6
> (2 4 6 8 10)
> (k m o q)
> Cannot resolve caller counter(Int, Rat, Int); none of these signatures
> match:
> (Int $start, Int $end, :$by = 1)
> (Str $start, Str $end, :$by = 1)
>   in block  at foo.p6 line 3
>
>
>
>
>
> Aaron Sherman, M.:
> P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
> Toolsmith, developer, gamer and life-long student.
>
>
> On Thu, Sep 8, 2016 at 2:41 PM, Trey Harris  wrote:
>
>> On Thu, Sep 8, 2016 at 9:23 AM Aaron Sherman a...@ajs.com
>>  wrote:
>>
>> I don't know Haskell, but isn't flip just:
>>>
>>> sub flip() { -> $b, $a, |c { f($a, $b, |c) } }
>>>
>>> And then:
>>>
>>> perl6 -e 'sub flip() { -> $a, $b, |c { f($b, $a, |c) } }; my  =
>>> flip  yas(1,2,3)'
>>> 213
>>>
>>> Yes—but my worry about that was that it wouldn’t carry over signature
>> constraints and coercions as a specific argument-flipper sub written with
>> the same signature (flipped). Haskell does deep type inference, unlike Perl
>> 6, so simply writing flip f x y = f y x is sufficient to get exactly the
>> same behavior in constrained or coercive contexts.
>>
>>
>>> Aaron Sherman, M.:
>>> P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
>>> Toolsmith, developer, gamer and life-long student.
>>>
>>>
>>> On Wed, Sep 7, 2016 at 6:13 PM, Brandon Allbery 
>>> wrote:
>>>
 On Wed, Sep 7, 2016 at 6:08 PM, Parrot Raiser <1parr...@gmail.com>
 wrote:

> There is a "flip" in P6, to reverse the characters in a string, and a
> "reverse", to return the elements of a list. Would either of those be
> an equivalent?
>

 Not without an "apply" mechanism used for function / method / operator
 invocations. Which is almost viable in Perl 6 since the parameters get
 passed as a list --- except that the list is only visible within the
 implementation, not at the call site (which is what "apply" does).

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

>>>
>>> ​
>>
>
>


Re: Justification for the "reversed" instruction format

2016-09-08 Thread Trey Harris
On Thu, Sep 8, 2016 at 9:23 AM Aaron Sherman a...@ajs.com
 wrote:

I don't know Haskell, but isn't flip just:
>
> sub flip() { -> $b, $a, |c { f($a, $b, |c) } }
>
> And then:
>
> perl6 -e 'sub flip() { -> $a, $b, |c { f($b, $a, |c) } }; my  = flip
>  yas(1,2,3)'
> 213
>
> Yes—but my worry about that was that it wouldn’t carry over signature
constraints and coercions as a specific argument-flipper sub written with
the same signature (flipped). Haskell does deep type inference, unlike Perl
6, so simply writing flip f x y = f y x is sufficient to get exactly the
same behavior in constrained or coercive contexts.


> Aaron Sherman, M.:
> P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
> Toolsmith, developer, gamer and life-long student.
>
>
> On Wed, Sep 7, 2016 at 6:13 PM, Brandon Allbery 
> wrote:
>
>> On Wed, Sep 7, 2016 at 6:08 PM, Parrot Raiser <1parr...@gmail.com> wrote:
>>
>>> There is a "flip" in P6, to reverse the characters in a string, and a
>>> "reverse", to return the elements of a list. Would either of those be
>>> an equivalent?
>>>
>>
>> Not without an "apply" mechanism used for function / method / operator
>> invocations. Which is almost viable in Perl 6 since the parameters get
>> passed as a list --- except that the list is only visible within the
>> implementation, not at the call site (which is what "apply" does).
>>
>> --
>> brandon s allbery kf8nh   sine nomine
>> associates
>> allber...@gmail.com
>> ballb...@sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>
> ​


Re: Justification for the "reversed" instruction format

2016-09-08 Thread Aaron Sherman
In Perl 6, we apply those constraints when you pass off the call to the
ultimate recipient, and that's important because that recipient can have
multiple signatures (and signatures can be added *after* you define the
flip).

For example:

$ cat foo.p6

sub flip() { -> $b, $a, |c { f($a, $b, |c) } }

multi sub counter(Int $start, Int $end, :$by=1) {
$start, *+$by ... $end
}
multi sub counter(Str $start, Str $end, :$by=1) {
($start.ord, *+$by ... $end.ord).map: {.chr}
}

my  = flip 

say flip-counter  10,   2, :by(2);
say flip-counter 'q', 'k', :by(2);
say flip-counter 3.7,   1, :by(2);

$ perl6 foo.p6
(2 4 6 8 10)
(k m o q)
Cannot resolve caller counter(Int, Rat, Int); none of these signatures
match:
(Int $start, Int $end, :$by = 1)
(Str $start, Str $end, :$by = 1)
  in block  at foo.p6 line 3





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


On Thu, Sep 8, 2016 at 2:41 PM, Trey Harris  wrote:

> On Thu, Sep 8, 2016 at 9:23 AM Aaron Sherman a...@ajs.com
>  wrote:
>
> I don't know Haskell, but isn't flip just:
>>
>> sub flip() { -> $b, $a, |c { f($a, $b, |c) } }
>>
>> And then:
>>
>> perl6 -e 'sub flip() { -> $a, $b, |c { f($b, $a, |c) } }; my  =
>> flip  yas(1,2,3)'
>> 213
>>
>> Yes—but my worry about that was that it wouldn’t carry over signature
> constraints and coercions as a specific argument-flipper sub written with
> the same signature (flipped). Haskell does deep type inference, unlike Perl
> 6, so simply writing flip f x y = f y x is sufficient to get exactly the
> same behavior in constrained or coercive contexts.
>
>
>> Aaron Sherman, M.:
>> P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
>> Toolsmith, developer, gamer and life-long student.
>>
>>
>> On Wed, Sep 7, 2016 at 6:13 PM, Brandon Allbery 
>> wrote:
>>
>>> On Wed, Sep 7, 2016 at 6:08 PM, Parrot Raiser <1parr...@gmail.com>
>>> wrote:
>>>
 There is a "flip" in P6, to reverse the characters in a string, and a
 "reverse", to return the elements of a list. Would either of those be
 an equivalent?

>>>
>>> Not without an "apply" mechanism used for function / method / operator
>>> invocations. Which is almost viable in Perl 6 since the parameters get
>>> passed as a list --- except that the list is only visible within the
>>> implementation, not at the call site (which is what "apply" does).
>>>
>>> --
>>> brandon s allbery kf8nh   sine nomine
>>> associates
>>> allber...@gmail.com
>>> ballb...@sinenomine.net
>>> unix, openafs, kerberos, infrastructure, xmonad
>>> http://sinenomine.net
>>>
>>
>> ​
>


Re: Justification for the "reversed" instruction format

2016-09-08 Thread Aaron Sherman
I don't know Haskell, but isn't flip just:

sub flip() { -> $b, $a, |c { f($a, $b, |c) } }

And then:

perl6 -e 'sub flip() { -> $a, $b, |c { f($b, $a, |c) } }; my  = flip
 yas(1,2,3)'
213


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


On Wed, Sep 7, 2016 at 6:13 PM, Brandon Allbery  wrote:

> On Wed, Sep 7, 2016 at 6:08 PM, Parrot Raiser <1parr...@gmail.com> wrote:
>
>> There is a "flip" in P6, to reverse the characters in a string, and a
>> "reverse", to return the elements of a list. Would either of those be
>> an equivalent?
>>
>
> Not without an "apply" mechanism used for function / method / operator
> invocations. Which is almost viable in Perl 6 since the parameters get
> passed as a list --- except that the list is only visible within the
> implementation, not at the call site (which is what "apply" does).
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>


Re: Justification for the "reversed" instruction format

2016-09-07 Thread Brandon Allbery
On Wed, Sep 7, 2016 at 6:08 PM, Parrot Raiser <1parr...@gmail.com> wrote:

> There is a "flip" in P6, to reverse the characters in a string, and a
> "reverse", to return the elements of a list. Would either of those be
> an equivalent?
>

Not without an "apply" mechanism used for function / method / operator
invocations. Which is almost viable in Perl 6 since the parameters get
passed as a list --- except that the list is only visible within the
implementation, not at the call site (which is what "apply" does).

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


Re: Justification for the "reversed" instruction format

2016-09-07 Thread Parrot Raiser
There is a "flip" in P6, to reverse the characters in a string, and a
"reverse", to return the elements of a list. Would either of those be
an equivalent?

On 9/6/16, Trey Harris  wrote:
> There’s a very common functional programming pattern, usually called flip;
> its implementation in Haskell is simply:
>
> flip   :: (a -> b -> c) -> b -> a -> cflip f x y =  f y x
>
> Getting the same behavior out of a bespoke function in Perl 6 would be easy
> for any particular case, but writing a general version of flip that would
> work universally with all binary operators would be a pain to get right
> (while maintaining *exactly* the same behavior and errors as the original
> in all conditions), wouldn’t it?
>
> If so, R is syntactic sugar, but very helpful syntactic sugar.
>
> On Tue, Sep 6, 2016 at 12:59 PM Aaron Sherman 
> wrote:
>
> Oh, and note that you can pass R'd reductions as if they were normal prefix
>> ops:
>>
>> $ perl6 -e 'sub dueet(, *@list) { op @list }; say dueet
>> :<[R-]>,
>> 1..100'
>> -4850
>>
>>
>>
>> On Tue, Sep 6, 2016 at 12:51 PM, Aaron Sherman 
>> wrote:
>>
>>>
>>>
>>> $ perl6 -e 'my @numbers = 1..100; say [-] @numbers; say [R-] @numbers'
>>> -5048
>>> -4850
>>>
>>> In general, it's kind of pointless with bare infix ops, as you can just
>>> reverse the arguments, but when reducing or the like, it becomes much
>>> more
>>> valuable.
>>>
>>>
>>>
>>> On Tue, Sep 6, 2016 at 12:43 PM, Parrot Raiser <1parr...@gmail.com>
>>> wrote:
>>>
 I've just stumbled across "reversed operators", e.g. say 4 R/ 12; # 3
 in the documentation. I'm curious to know why the language includes
 them? I'm having trouble understanding where they would be useful.

>>>
>>>
>> ​
>


Re: Justification for the "reversed" instruction format

2016-09-07 Thread Trey Harris
There’s a very common functional programming pattern, usually called flip;
its implementation in Haskell is simply:

flip   :: (a -> b -> c) -> b -> a -> cflip f x y =  f y x

Getting the same behavior out of a bespoke function in Perl 6 would be easy
for any particular case, but writing a general version of flip that would
work universally with all binary operators would be a pain to get right
(while maintaining *exactly* the same behavior and errors as the original
in all conditions), wouldn’t it?

If so, R is syntactic sugar, but very helpful syntactic sugar.

On Tue, Sep 6, 2016 at 12:59 PM Aaron Sherman 
wrote:

Oh, and note that you can pass R'd reductions as if they were normal prefix
> ops:
>
> $ perl6 -e 'sub dueet(, *@list) { op @list }; say dueet :<[R-]>,
> 1..100'
> -4850
>
>
>
> On Tue, Sep 6, 2016 at 12:51 PM, Aaron Sherman 
> wrote:
>
>>
>>
>> $ perl6 -e 'my @numbers = 1..100; say [-] @numbers; say [R-] @numbers'
>> -5048
>> -4850
>>
>> In general, it's kind of pointless with bare infix ops, as you can just
>> reverse the arguments, but when reducing or the like, it becomes much more
>> valuable.
>>
>>
>>
>> On Tue, Sep 6, 2016 at 12:43 PM, Parrot Raiser <1parr...@gmail.com>
>> wrote:
>>
>>> I've just stumbled across "reversed operators", e.g. say 4 R/ 12; # 3
>>> in the documentation. I'm curious to know why the language includes
>>> them? I'm having trouble understanding where they would be useful.
>>>
>>
>>
> ​


Re: Justification for the "reversed" instruction format

2016-09-06 Thread Aaron Sherman
Oh, and note that you can pass R'd reductions as if they were normal prefix
ops:

$ perl6 -e 'sub dueet(, *@list) { op @list }; say dueet :<[R-]>,
1..100'
-4850



On Tue, Sep 6, 2016 at 12:51 PM, Aaron Sherman 
wrote:

>
>
> $ perl6 -e 'my @numbers = 1..100; say [-] @numbers; say [R-] @numbers'
> -5048
> -4850
>
> In general, it's kind of pointless with bare infix ops, as you can just
> reverse the arguments, but when reducing or the like, it becomes much more
> valuable.
>
>
>
> On Tue, Sep 6, 2016 at 12:43 PM, Parrot Raiser <1parr...@gmail.com> wrote:
>
>> I've just stumbled across "reversed operators", e.g. say 4 R/ 12; # 3
>> in the documentation. I'm curious to know why the language includes
>> them? I'm having trouble understanding where they would be useful.
>>
>
>


Re: Justification for the "reversed" instruction format

2016-09-06 Thread Aaron Sherman
$ perl6 -e 'my @numbers = 1..100; say [-] @numbers; say [R-] @numbers'
-5048
-4850

In general, it's kind of pointless with bare infix ops, as you can just
reverse the arguments, but when reducing or the like, it becomes much more
valuable.



On Tue, Sep 6, 2016 at 12:43 PM, Parrot Raiser <1parr...@gmail.com> wrote:

> I've just stumbled across "reversed operators", e.g. say 4 R/ 12; # 3
> in the documentation. I'm curious to know why the language includes
> them? I'm having trouble understanding where they would be useful.
>


Re: Intalling Perl6

2016-06-26 Thread Brandon Allbery
On Sun, Jun 26, 2016 at 1:51 PM, Julian Brown  wrote:

> I search for packages on Debian Jessie for Perl 6 and found Rakudo and
> Parrot.
>
> Does everyone install per user and not system-wide?
> Does anyone use Parrot instead of Moar?
>

Debian is, as always, way behind. The Parrot backend hasn't even been
supported for over a year. (There should be be newer packages in unstable,
and possibly already in testing.)

System-wide installation was broken when the new CompUnitRepo stuff was
added, and was only recently fixed --- but still needs more testing, so if
you choose to do a system-wide install of a sufficiently recent rakudo (I
think this means 2016.05 or later) you should expect to be a guinea pig.

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


Re: can a method name contain a funny character?

2016-05-21 Thread yary
Thanks for the in-depth analysis. My misunderstanding was about what an
identifier considers a number; I have no well-thought-out ideas on the
subject of what an identifier ought to be.

Having the docs mention that "number" means only characters with a Unicode
Property GeneralCategory of Nd might have prevented me from looking through
the NumericTypes for a pattern. With more experimenting, I might have
noticed that De was the one that always worked, since De has a one-to-one
correspondence with Nd...

-y


Re: can a method name contain a funny character?

2016-05-21 Thread Larry Wall
On Fri, May 20, 2016 at 09:39:30AM -0400, yary wrote:
: On Tue, Apr 12, 2016 at 6:12 PM, Brandon Allbery 
: wrote:
: > I was explaining why some "symbols" are acceptable to the parser. Which
: one
: > is more appropriate is not my call,
: 
: I was thinking about what exactly are valid identifiers in Perl6/rakudo's
: implementation. The docs 
: say:
: 
: An identifier is a primitive name, and must start with an alphabetic
: character (or an underscore), followed by zero or more word characters
: (alphabetic, underscore or number). You can also embed dashes - or single
: quotes ' in the middle, but not two in a row.

At this point, "number" means only characters with a GeneralCategory
of Nd.  We could talk about generalizing that, but there are potential
issues.  We can't simply extend it to No characters, because then

pi²

would misparse as a 3-character identifier.

: Experimenting with some of the numeric codes from Wikipedia
: , some of the numeric
: codes seem inconsistent-

Note that, even if we used this table, we could not distinguish ² from ② and 
such.

: > my $_६೬ퟨ = ६೬ퟨ # "De" Devanagari, Kannada, Mathematical. "De" is all
: good.
: 666

That's fine, those work because of the Nd general property, so they're 
equivalent
to 0..9 as far as we're concerned.

: > my $x六 = 6 #  "Nu" Han number 6
: 6
: >  say 六
: ===SORRY!=== ...

Note that 六 works in identifiers by virtue of being not numeric at all,
but by being in general category Lo, that is, it's a "letter other",
so considered alphabetic.

: > say ௰  # "Nu" Tamil number 10
: 10
: > my $x௰ = 5
: ===SORRY!=== Error ...

Excluded because it's No, not Nd.

: > say ① + 3 # "Di" 1 in typographic context has value 1
: 4
: > my $b① = 44 "Di" 1 not valid in identifier
: ===SORRY!=== Error ...

① is indistinguishable from superscripts, even by "Di", and falls into
the No general category, so excluded.

: Some numeric codepoints are recognized as such, yet Rakudo isn't allowing
: them in identifiers. Especially confounding is the treatment of the "Han
: number 6" and "Tamil number 10", both of which are unicode "Nu" numeric.
: The Tamil is recognized as a number on its own but not as an identifier;
: the Han is allowed in an identifier but isn't recognized as a number!

We currently rely only on GeneralCategory.  I don't believe we use
NumericType anywhere in parsing Perl 6.

: Is there some deeper rule at work here- which could be added to the
: documentation? Or are these bugs?

Not a bug, but potentially negotiable.  It simply comes down to Nd vs
No at the moment.  One could argue that we could notice superscripts
as a separate category and treat them differently, but there are two
arguments against that.

The first is that we'd like to keep the basic identifier rules fairly
simple.  We're already pushing the state of the art here, and I don't
see much benefit in making the rules more arcane that they are.

The second argument is that we should probably reserve syntax for the
user here.  Once we get slangs fully hooked up, we can easily let users
define identifiers to include ①  and such.  But it's just as likely,
perhaps more likely, that the user will want to use ①  for a postfix,
just like we currently treat superscripts as powers.  We can't guess
(well, we *could* guess, but can't know) which way the user will want to
use these, so the conservative approach is to make neither of them work,
and let the user take an additive approach, rather than forcing them to
use a subtractive approach if we guessed wrong.

Larry


Re: can a method name contain a funny character?

2016-05-20 Thread yary
To be clear, I expect that "number" in "followed by zero or more word
characters (alphabetic, underscore or number)" means "if Unicode thinks
it's numeric, you can use it in an identifier after the first character."

I don't expect that every numeric codepoint in Unicode must evaluate to
number in the Perl6 settings. We can have Numeric::Roman,
Numeric::Counting-Rod, Numeric::Euler etc. for those, if someone cares
enough to write & use them.


Re: can a method name contain a funny character?

2016-05-20 Thread yary
On Tue, Apr 12, 2016 at 6:12 PM, Brandon Allbery 
wrote:
> I was explaining why some "symbols" are acceptable to the parser. Which
one
> is more appropriate is not my call,

I was thinking about what exactly are valid identifiers in Perl6/rakudo's
implementation. The docs 
say:

An identifier is a primitive name, and must start with an alphabetic
character (or an underscore), followed by zero or more word characters
(alphabetic, underscore or number). You can also embed dashes - or single
quotes ' in the middle, but not two in a row.


Experimenting with some of the numeric codes from Wikipedia
, some of the numeric
codes seem inconsistent-

> my $_६೬ퟨ = ६೬ퟨ # "De" Devanagari, Kannada, Mathematical. "De" is all
good.
666

> my $x六 = 6 #  "Nu" Han number 6
6
>  say 六
===SORRY!=== ...
> say ௰  # "Nu" Tamil number 10
10
> my $x௰ = 5
===SORRY!=== Error ...

> say ① + 3 # "Di" 1 in typographic context has value 1
4
> my $b① = 44 "Di" 1 not valid in identifier
===SORRY!=== Error ...

Some numeric codepoints are recognized as such, yet Rakudo isn't allowing
them in identifiers. Especially confounding is the treatment of the "Han
number 6" and "Tamil number 10", both of which are unicode "Nu" numeric.
The Tamil is recognized as a number on its own but not as an identifier;
the Han is allowed in an identifier but isn't recognized as a number!

Is there some deeper rule at work here- which could be added to the
documentation? Or are these bugs?

-y


Re: Unwanted failure and FAILGOAL

2016-05-11 Thread Moritz Lenz

Hi,

On 05/11/2016 07:45 AM, Richard Hainsworth wrote:

I have the following in a grammar

 rule TOP{ ^ + $ };

 rule statement  {  '=' 
  | { { self.panic($/, "Declaration syntax
incorrect") } }
 };

 rule endvalue   {  '(' ~ ')' 
  | { self.panic($/, "Invalid declaration.") }
 }

The grammar parses a correct input file up until the end of the file. At
that point even if there is no un-consumed input, there is an attempt to
match , which fails. The failure causes the panic with 'Declaration
syntax'.

Am I missing something simple here?

I would have thought  (though this is only a very newbie assumption)
that if the end of the input being sent to the grammar has been reached
after the last  has been matched, then there should be no
reason for the parse method to try to match  again, and if it
fails to test for the end of input.


This is not how regexes or grammars work.

The + quantifier tries as many times as possible to match the regex. It 
doesn't look ahead to see if more characters are available, and it 
doesn't know about the end-of-string anchor that comes next in the grammar.


In fact, it doesn't know if the rule it quantifies might have a way to 
match zero characters. In this case, it would be wrong behavior to not 
do a zero-width at the end of the string.


As for improving the error reporting from within a grammar, there are 
lots of way to get creative, and I'd urge you to read Perl 6's own 
grammar, which is a good inspiration for that.

See https://github.com/rakudo/rakudo/blob/nom/src/Perl6/Grammar.nqp

One thing you could do is structure the statement rule differently:

rule statement {

   [  '=' 
   || { self.panic($/, "Invalid declaration.")
   ]
}

And maybe also TOP:

rule TOP{ ^ [  || . { self.panic($/, "Expected a 
statement") } ] $ };


That extra dot before the panic ensures it's not called at the end of 
the string. If you don't want that, you could also do


[  || $ || { self.panic(...) } ]

Cheers,
Moritz


Re: Unwanted failure and FAILGOAL

2016-05-11 Thread Damian Conway
Hi Richard,

Not a complete answer to your question;
just an observation about your grammar:

>  rule TOP{ ^ + $ };
>
>  rule statement  {  '=' 
>  | { { self.panic($/, "Declaration syntax incorrect") } }
>  };
>
>  rule endvalue   {  '(' ~ ')' 
>  | { self.panic($/, "Invalid declaration.") }
>  }

That's more or less the equivalent of:

sub TOP   {
die if !at_start_of_input();
loop { last unless try statement() };
die if !at_end_of_input();
  }

sub statement {
try { id(); match_literal('='); endvalue() }
  or
die "Declaration syntax incorrect";
  }

sub endvalue  {
try { keyword(); match_literal('('); pairlist();
match_literal(')') }
  or
die "Invalid declaration."
  }

In which case, would you really have expected a call to TOP()
NOT to throw an exception from statement(), the first time statement()
couldn't match (as it inevitably won't if we're at the end of the input)???

If these were subroutines, I suspect you'd have written something
more like:

sub statement {
try { id(); match_literal('='); endvalue() }
  or

*!at_end_of_input()&& die
"Declaration syntax incorrect"*
  }

sub endvalue  {
try { keyword(); match_literal('('); pairlist();
match_literal(')' }
  or

*!at_end_of_input()&& die
"Invalid declaration.";*
  }

which, in a regex, would be something like:

   rule TOP{ ^ + $ };

   rule statement  {
  '=' 
   |
* \S  **# ...means we found something else, so...*
* { self.panic($/, "Declaration syntax incorrect") }*
   };

   rule endvalue   {
  '(' ~ ')' 
   |
* \S  **# ...means we found something else, so...*
* { self.panic($/, "Invalid declaration.") }*
   }

Though, personally, I'd have been inclined to write it like this:

rule TOP{ ^  +  *[ $ |  ]*  }

rule statement  { 'ID' '='  }

rule endvalue   { 'keyword' '(' ~ ')' 'pairlist' }



*rule unexpected { $ = (\N+)  {
self.panic($/,"Expected statement but found '$'")
}}*

In other words: after the statements, we're either at the end of the input,
or else we found something unexpected, so capture it and then report it.

HTH,

Damian


Re: A practical benchmark shows speed challenges for Perl 6

2016-03-30 Thread yary
On Wed, Mar 30, 2016 at 3:20 PM, Elizabeth Mattijsen  wrote:
> Thanks for your thoughts!
>
> I’ve implemented $*DEFAULT-READ-ELEMS in 
> https://github.com/rakudo/rakudo/commit/5bd1e .
>
> Of course, all of this is provisional, and open for debate and bikeshedding.


Thanks! And that was fast!

Allowing DEFAULT-READ-ELEMS to be set from the environment's a good
idea that I hadn't thought of- since it is a machine-dependent
performance tweak, letting it be set outside the code is a good idea.

I had originally envisioned this as an "option" to "sub open" for
fine-grained control as to which IO::Handles got what
DEFAULT-READ-ELEMS, but I'm not sure it belongs there. After all it is
a performance-related tweak and I'm liking the idea of it being
primarily set from the environment; setting it in the code means
you're writing something for a particular host, don't need to change
the spec to support that.

Is there anything similar on the "write" side- output buffering- that
could use this treatment?

-y


  1   2   3   4   5   6   7   8   9   10   >