Re: Checking for nil return

[yary]

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

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

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

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

-y


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

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

Re: Checking for nil return

[yary]

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

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

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

-y


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

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

Re: Checking for nil return

[yary]

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

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

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

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

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

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



-y


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

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

Re: Checking for nil return

[yary]

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

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

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

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

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

-y


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

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

Checking for nil return

[yary]

Is this a known issue, or my misunderstanding?

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

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

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

The subtype works as I expect as an the argument check

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

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

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

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

-y

Re: "temp" vs "my"

[yary]

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

-y

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

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

"temp" vs "my"

[yary]

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

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

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

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

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

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

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

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


-y

Re: 3 kinds of yadda

[yary]

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

at least that's my impression

-y

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

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

Is negative lookbehind behaving here?

[yary]

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

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

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

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

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

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

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

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

[yary]

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

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

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

-y

On Wed, Mar 7, 2018 at 5:16 PM, Solomon Foster <colo...@gmail.com> wrote:

> On Sun, Mar 4, 2018 at 8:49 AM, yary <not@gmail.com> 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

[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

[yary]

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

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

[yary]

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

"  Why so large?

   Why not zero?  "

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

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

[yary]

Zeroing in on one point:

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

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

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

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

-y

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

[yary]

A bit of a digression around marketing/evangelizing


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

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

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

-y

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

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

Naming debate- what's the location for it?

[yary]

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: fixing infinities and ranges etc

[yary]

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

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

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

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

Re: can a method name contain a funny character?

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

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

[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: A practical benchmark shows speed challenges for Perl 6

[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

Re: A practical benchmark shows speed challenges for Perl 6

[yary]

Cross-posting to the compiler group-

On Wed, Mar 30, 2016 at 8:10 AM, Elizabeth Mattijsen  wrote:
> If you know the line endings of the file, using 
> IO::Handle.split($line-ending) (note the actual character, rather than a 
> regular expression) might help.  That will read in the file in chunks of 64K 
> and then lazily serve lines from that chunk.

This reminds me of a pet peeve I had with p5: Inability to easily
change the default buffer size for reading & writing.

I'm the lone Perl expert at $work and at one point was trying to keep
a file processing step in perl. These files were about 100x the size
of the server's RAM, consisted of variable-length newline-terminated
text, the processing was very light, there would be a few running in
parallel. The candidate language, C#, has a text-file-reading object
that lets you set its read-ahead buffer on creation/opening the file-
can't remember the details. That size had a large impact on the
performance of this task. With perl... I could not use the
not-so-well-documented IO::Handle->setvbuf because my OS didn't
support it. I did hack together something with sysread, but C# won in
the end due partly to that.

It seems this "hiding-of-buffer" sub-optimal situation is being
repeated in Perl6: neither https://doc.perl6.org/routine/open nor
http://doc.perl6.org/type/IO::Handle mention a buffer, yet IO::Handle
reads ahead and buffers. Experience shows that being able to adjust
this buffer can help in certain situations. Also consider that perl5
has defaulted to 4k and 8k, whereas perl6 is apparently using 64k, as
evidence that this buffer needs to change as system builds evolve.

Please make this easily readable & settable, anywhere it's implemented!


-y

Blogging on Perl6 anonymous proto/multi

[yary]

Back in June of last year some discussion about multi-subs got me
thinking and posting about anonymous proto/multi routines here. It's
been bubbling in the back of my mind since then, and as my Valentine
to the language, I've posted my thoughts at
http://blogs.perl.org/users/yary/2016/02/apropos-proto-perl6c-multi-thoughts.html

It's a more coherent (I hope!) follow-up to
https://www.mail-archive.com/perl6-language@perl.org/msg34937.html

Would appreciate feedback on the merits or perils of exposing a way
for creating a truly anonymous multi. It's something the design spec
isn't explicit on.

-y

Re: It's time to use "use v6.c"

[yary]

"panda --force install p6doc" fixed it for me!

It's time to use "use v6.c"

[yary]

this morning I installed the 2016.01 R*. Now I'm at the NYC perl6
study group, and a helpful neighbor asked me to start up p6doc. It
gave me an error about EVAL being dangerous, and after opening a
ticket & adding "use MONKEY-SEE-NO-EVAL" to my source, I got
"Undeclared name:CompUnitRepo used at line 32"

And it looks like my p6doc is from an earlier install, circa July
2015. Now, if back in July, p6doc had "use 6.0.0" in it, and if today,
Rakudo would see that and say "ah back then we didn't need
SEE-NO-EVAL," then p6doc would still work.

Please module authors, start using "use 6.c;" at the top of your
modules. Please Rakudo contributors, consider making spec
compatibility as described in S11 a reality:

"say something like

use Perl:<6.0>;
use Perl:<6.0.0>;
use Perl:<6.2.7.1>;

if you want to lock in a particular set of semantics at some greater
degree of specificity."

-y

Re: It's time to use "use 6.c"

[yary]

Thanks all... I expect hiccups... just venting to help (future coders
and current self)... while we're on this topic

a) lwp-download.pl doesn't have a "use 6". Since Windows ignores the
shebang, it invokes perl5 which is registered to handle "pl" files,
and gives a bunch of syntax errors. If it did have "use 6" at the top,
then it would give a single more meaningful error... yet another
reason for module authors to put "use 6" in their code.

b) subject line should be "use 6.c", the "v" is depreciated... edited

Re: Rationale for $!

[yary]

On Wed, Jan 27, 2016 at 11:00 AM, Felipe Gasper 
wrote:

> Could it not be:
>
> try my $f = open(...) or die …
>

Don't need a "try" there to make it work. An exception object/failure is
false, so "my $f = open(...) or die" will assign the exception to $f, which
is false, causing the "die" to execute.

-y

Re: Exploit the versioning (was Re: Backwards compatibility and release 1.0)

[yary]

Short answer: everything must declare which semantics it expects-
everything in Panda/CPAN at least. And we already knew it, just need
to do it.

Full post: This thread points to a bigger problem, which has a
solution that is both cultural and technical.

Perl5 has a colossal code corpus, humbling in its pervasiveness. Perl
culture understands the value of backward compatibility to keep that
code working as the language evolves and the interpreter improves;
Perl-porters master the compatibility dance and pay for it with
cognitive complexity.

Perl5 has a tension between moving forward and keeping all existing
code running as it was first written. The backward-compatibility
contract is beneficial to the community, and yet it is also friction,
drag on the perl interpreter's progress.

In Perl6 culture, it's time to also adopt the ethic of forward
compatibility where each module states exactly what Perl6 semantics
its coded for. This is not a new idea, S11 says it: "modules are also
required to specify exactly which version (or versions) of Perl they
are expecting to run under, so that future versions of Perl can
emulate older versions of Perl"

That's the cultural part of the solution: we need to start putting
"use 6.0.0" at the start of our code now. The technical part of the
solution is for post-Christmas Perl 6.0.1 to respect that declaration
and "do the right thing."

And more immediately, the community fix is to get the word out; the
technical fix is to s/use v6;/use v6.0.0;/ for everything in Panda
that doesn't get the message by the release date. The old way "use
v6;" means "use any Perl6" and is what got us here: "6.*" is against
the spirit of "exactly which version (or versions) of Perl they are
expecting to run under."

... As for the specific issue of to grin widely or flatly, to :D or :_
defaultly, I'll defer discussing until 6.0.1.  (Earlier I posted a
more specific answer to Darren only; this post is more robust.)

Re: Backwards compatibility and release 1.0

[yary]

On 10/13/2015 03:17 PM, Moritz Lenz wrote:
>... We have 390+ modules, and hand-waving away all
> trouble of maintaining them seems a bit lofty.
> ... a large percentage of the module updates are done by group of
> maybe five to a dozen volunteers. ... 5 people updating 70% of 390
> modules. Modules they are usually not all that familiar with, and
> usually don't have direct access. So they need to go through the pull
> request dance, waiting for reaction from the maintainer. In short, it
> sucks.

The idea is to make the maintenance one-time and as minimal as
possible. In the "Exploit the versioning" thread Darren D & I advocate
changing the version declaration at the top of existing modules to
"use v6.0.0.0" and punting on the default-defined-parameter question
until after Christmas. Changing "v6" to "v6.0.0.0" is a one-line
change to ease forward compatibility, and it eases the burden on
module authors. It's practical: Rakudo Star already accepts "use
v6.0.0.0;" without error. (In fact it even accepts "use v88;" which I
do not recommend in production :)


On Thu, Oct 15, 2015 at 12:48 AM, Richard Hainsworth
 wrote:
> Some suggestions:

Reading these brings MetaCPAN to mind:

>
> 1) On the perl 6 modules page (modules.perl6.org) , sort the modules by
> number of Badges, ...
> 2) Add another badge for 'reviewed'. ...
>
> 3) Would it be possible to develop a sort of Citation Index? That is the
> number of times a module uses another module? ...

MetaCPAN's "search" shows most of that info: how many people have
"favorited" it, how many reviews it has and the average "stars". Click
on a result, and it has "citations" linked to as "reverse
dependencies". Search page is not flexibly sortable in its default web
interface, but that is fixable. So... "all we need" are the tuits to
modify MetaCPAN to S22 and get it up on the web... sounds like fun,
not trivial though!

Or in other words, all good ideas that seem to have arose organically
in the P5 ecosystem. Let's adopt them back into P6 when we are
implementing the analogous tools/sites.

> 4) How about developing the 'bundle' idea more? Perhaps, putting Bundles on
> the Perl6 Modules top page, starting with Task::Star? Bundles could be
> moderated more strictly. Perhaps Bundle authors would need to supply a
> mandate, eg. "Bundle for GUI  development", or "Essential beginners bundle".
> Also bundle authors would need to have vetted the modules in the bundle,
> especially those without all badges.

Matches a comment about Perl 6 being like Linux, in how distributions
choose what to bundle with it. Rakudo Star has its choice of useful
modules bundled with it; other people's curatorial choices would be
interesting too...

Re: [perl6/specs] 614b6f: doc with/without

[yary]

with, without look awesome.

-y

On Sat, Aug 8, 2015 at 2:38 PM, GitHub nore...@github.com wrote:

   Branch: refs/heads/master
   Home:   https://github.com/perl6/specs
   Commit: 614b6f36e1cae4c787e378bc6ab2afa1f86de1f0

 https://github.com/perl6/specs/commit/614b6f36e1cae4c787e378bc6ab2afa1f86de1f0
   Author: TimToady la...@wall.org
   Date:   2015-08-08 (Sat, 08 Aug 2015)

   Changed paths:
 M S04-control.pod

   Log Message:
   ---
   doc with/without

What's the intent of anon proto/anon multi?

[yary]

Rakudo (both star 201503  rakudo-moar 7b5256) complains about anon
multi, saying Cannot use 'anon' with individual multi candidates. Please
declare an anon-scoped proto instead in response to anon multi foo (Int
$x) { $x + 1 };

Given that message, I created an anon proto foo and assigned it to a
scalar:

perl6 -e my $y=anon proto foo (|) {*}; multi foo (Int $x) { $x + 1 };  say
$y.name; say $y(7)

which says foo, showing that the anonymous dispatcher does know its name,
and then fails with Cannot call foo(Int); none of these signatures match:
- no signatures listed.

My understanding of anon is that it prevents the following declaration
from being installed into any namespace, with only the object storing its
name. What seems to happen, is that the following multi foo creates a new
dispatcher, because it can't see the anon proto foo. The the existing
anonymous dispatcher can't ever have any candidates.

Perl6 IRC's bot tells me that std accepts anon multi declarations
without complaint. That, plus the not-so-useful behavior of anon proto
makes me wonder what the intent is with anon proto/multi. Three thoughts
come to me:

1. An anon proto is useful in some way I don't know. Maybe it's good for
run-time dispatcher twiddling eg. my $int_inc = sub (Int $x) { $x + 1
}; $dispatcher=anon
proto Inc-Anon (Num $z) {*}; $dispatcher.add-multi($int_inc); say 'Perl ',
$dispatcher(5);

2. Rakudo currently seems to implement multi-subs with each multi
declaration looking for a proto to hang on to at compilation, creating
one in the same scope if none are found. If that's the case, perhaps anon
proto should be illegal, and anon multi would hide that multi signature
 sub from everything except its proto- which would know because the when
the anon-multi-sub was first created, it installed itself into its
(non-anon-)proto.

3. If the responsibility of binding multi to proto was in proto and
delayed until runtime, then an $a = anon proto foo could indeed find any
multi foo declared in the same scope. Drawback is potential for confusion
if anything calls foo directly, it would create a new dispatcher.

My speculation on implementation is haphazard and not well informed. What's
the *intent *of anon proto and perhaps anon multi subs? Std and Rakudo
have different ideas of what is legal, and the current implementation hints
at untapped potential.

-y

Re: Types for Perl 6: request for comments

[yary]

Now that I've read ahead to 3.4, the multi method solution shown can be a
little simpler, just need to add multi to the original equal methods,
see attached.

-y

On Tue, Jun 30, 2015 at 4:16 PM, yary not@gmail.com wrote:

 Section 3.2's example does not fail for the given reason This tries to
 access the c instance variable of the argument $b thus yielding a
 run-time error - instead Perl6 more correctly complains that it was
 expecting a ColPoint, but got a Point instead. Indeed one cannot generally
 replace a subtype with its parent type, only the other way around. Can
 correct by re-writing along the lines of This fails to dispatch because
 ColPoint's equal method requires a ColPoint argument, but we are calling
 it with the supertype Point, which does not compose with the method's
 signature.

 (Furthermore if equal is defined as a multi method, then the
 dispatcher chooses Point's equal method, and the example returns
 True, which all looks good to me. But it doesn't illustrate the paper's
 point.)

 -y




Point.p6
Description: Binary data

Re: Types for Perl 6: request for comments

[yary]

Section 3.2's example does not fail for the given reason This tries to
access the c instance variable of the argument $b thus yielding a run-time
error - instead Perl6 more correctly complains that it was expecting a
ColPoint, but got a Point instead. Indeed one cannot generally replace a
subtype with its parent type, only the other way around. Can correct by
re-writing along the lines of This fails to dispatch because ColPoint's
equal method requires a ColPoint argument, but we are calling it with the
supertype Point, which does not compose with the method's signature.

(Furthermore if equal is defined as a multi method, then the dispatcher
chooses Point's equal method, and the example returns True, which all
looks good to me. But it doesn't illustrate the paper's point.)

-y

Re: Types for Perl 6: request for comments

[yary]

The anon does something. For example this code prints bob

my $routine = proto bar (|) { * };
multi bar (Int $x) { $x - 2 }
multi bar (Str $y) { $y ~ 'b' }

say $routine('bo');

but change the first line to my $routine = anon proto bar (|) { * }; and
you get an error

Cannot call 'bar'; none of these signatures match:
  in block unit at type.p6:5

- and that makes sense to me, because anon means no name gets installed
in any scope, and thus the multi bar declarations have nothing to hold on
to. What confused me is that the $sub_anon example in my last email works,
I expected it to give the same kind of error! It looks like adding the
anon to the proto simply disconnects the proto from the multi, making it
like there was no proto at all.

-y

Re: Types for Perl 6: request for comments

[yary]

I'm reading it a bit at a time on lunch break, thanks for sending it along,
it's educational.

My comments here are all about the example on the top of page 5, starting
with the minutest. First a typo, it says subC where it should say sumC

multi sub sumB is ambiguous, due to your use of ;; there. And sumI
*should* be ambiguous, because the caller sumC(Int $x ;; $y) {sumI($x,$y)}
means sumI will always be called with $x - Int and varying $y. That
example could use a little re-working.

Note to Rakudo-porters: Can the error message remember the ;; in the
sig ? The message from Rakudo * has a ,  where the source has ;; which
is misleading:
Ambiguous call to 'sumB'; these signatures all match:
:(Bool $y, Bool $x)
:(Bool $y, Int $x)

The comment  example about considering anonymous multi definitions in the
same block to define the same anonymous function does show the feature's
desirability, but that proposed syntax might be problematic. (Deciding if 
how to make that part of the syntax is not in the scope of the paper, but
since you brought it up) What if one wants to define two different
anonymous multi subs in the same scope? A contrived example:

sub pick_multi (Bool $p) {
  my multi sub hmmI(Int $y) { 2 * $y }
  my multi sub hmmI(Bool $y) { $y }

  my multi sub hmmB(Int $y) { 1 + $y  }
  my multi sub hmmB(Bool $y) { ! $y }

  $p ?? hmmI !! hmmB
}

Yes, one could enclose each anon-multi-set in a do block, but it feels to
me that defining an anonymous multi-sub should require a single statement,
to avoid unintentional co-mingling within a block.

Anonymous multi-subs

[yary]

Now that I've thought about it for 90 seconds (not fully-formed idea), if
one were to have an anonymous multi-sub, it ought to be constructed from a
list of *signature*, *body *pairs.

And/or, any non-finalized sub could have a method to add another *signature,
body* to its dispatch list.

apologies if this discussion is already captured in a design doc, I am
posting this without having read much of the past.

and now, back to our regularly scheduled programming.

-y

Rationalizing numeric types

[yary]

Thinking over my programming career, there were a few occasions I had to
spend time working around floating point errors, and it was a nuisance.
There were even fewer times when I worked with transcendental numbers-
programs dealing with geometry or tones or logarithmic scales- and those
times, floating point was good enough.

Which is to say, Perl 6's Rats would have solved my nuisance issues, and I
would not have appreciated exact types for irrational numbers in my tasks
to date.

Still, I couldn't resist thinking about them and web-searching on them a
bit more, and here's my brain-dump. Periodic continued fractions
https://en.wikipedia.org/wiki/Continued_fraction can represent any quadratic
root
http://www.millersville.edu/~bikenaga/number-theory/periodic-continued-fractions/periodic-continued-fractions.html.
Haskel has this package implementing a quadratic irrational type
https://hackage.haskell.org/package/quadratic-irrational-0.0.2/docs/Numeric-QuadraticIrrational.html,
and it can translate between those and continued fractions. ... here is a
decent intro to continued fractions
http://www.maths.surrey.ac.uk/hosted-sites/R.Knott/Fibonacci/cfINTRO.html.

That's a comprehensive answer for square roots of rationals, but not
for transcendental
numbers http://sprott.physics.wisc.edu/pickover/trans.html. My math is
not so hot, but perhaps a generalized continued fraction
https://en.wikipedia.org/wiki/Generalized_continued_fraction type could
perfectly represent transcendental constants like pi and e, with trig and
log/exponentiation functions using them. Then Perl 6 could get this famous
relationship *exactly right*:

say 1 + e ** (pi * i)

... though I suspect it really does take a symbolic math package to get all
combinations of the trig  exponential functions right
https://cloud.sagemath.com/projects/3966ff36-7109-449d-83a9-49e48e078fea/files/2015-06-22-133206.sagews
.

-y

Re: Language design

[yary]

I like the explanation of how Rats solve a class of rounding errors,
0.3 - (0.2 + 0.1) equals exactly 0 for example. On the other hand,
it's still a compromise that's shifting closer to correctness, fixing
a bunch of potential bugs, but not all in that class:

Rakudo:
 say 2 - (sqrt 2) ** 2
-4.44089209850063e-016

That's OK by me. I can also envision a type  which can perfectly
represent trigonometric and polynomial roots (backed by a symbolic
math package?), that would solve this problem. I can see why that
might be good in the core, for the same reasons that Rats are... or
maybe put them in a module, along with non-integer exponents and trig
functions, so if you can use functions with irrational numbers in
their domain, you also get the numeric types that can perfectly
represent them.

-y

Re: The invocation operators .* and .+

[yary]

On Wed, Jun 17, 2015 at 1:29 PM, Aristotle Pagaltzis pagalt...@gmx.de wrote:
 * yary not@gmail.com [2015-06-17 17:10]:
 Perl6's TEARDOWN

 Sorry for the confusion. It’s not in Perl 6. I invented .teardown for
 this example because I didn’t want to call it .destroy – that’s all.

That's good to know. I did find DESTROY mentioned (in a parenthetical
comment) in http://design.perl6.org/S12.html, which also describes
what .?, .*, .+ do, without describing how they are useful in the way
this email thread does. The synopses are programmer reference docs,
good at saying what, I need to browse through
http://perl6.org/documentation/ for user docs showing why... and
something like your example would be good in a user doc.

Re: The invocation operators .* and .+

[yary]

A couple years ago I wrote a little Perl6 in response to a challenge,
and it took me a while to figure out BUILD, BUILDALL, and new().
Learning the object model meant reading what was available on the web
plus some time on the #perl6 IRC channel. I managed to get it all
working properly for my little code, but it didn't make complete sense
to me until later when I did a Perl5 project with Moose. Moose's
cookbooks, examples, and documentation explained the concepts 
implementation a few different ways. Moose borrowed a lot from Perl6,
and it helped me understand the why's  how's of Perl6.

Alas, Perl6's distributed docs is a known issue (so much to write!).
As an illustration, this thread got me curious as to these .+ and .*
operators and Perl6's TEARDOWN, so I searched for perl6 object
teardown. The first link I clicked from that search was
http://doc.perl6.org/language/objects - which is a great intro - but
it doesn't mention teardown/destruction, nor these operators. perl6
object +teardown didn't seem to return any user-facing docs at all,
other than Apocalypses which are not current. Searching for perl6
object destroy shows me that it is implemented via
http://perl6.org/compilers/features - with no links to spec or code.

I enjoy reading these explanations as to how these operators are
useful, and the example referencing TEARDOWN, can they go into some
documentation for future readers? In a context to help me see how they
fit? Or is there already a doc that I'm not seeing in my searches?

-y

Re: [perl6/specs] 126dd3: Mark .exists and .delete as deprecated, use :...

[yary]

I suspect there are copy-paste errors on the delete sections of the new text:

... the
+normal way to test for existence is to apply the C:delete adverb to a
+subscripting operation.

The :delete adverb tests for existence?
-y


On Mon, Sep 30, 2013 at 6:09 AM, GitHub nore...@github.com wrote:
   Branch: refs/heads/master
   Home:   https://github.com/perl6/specs
   Commit: 126dd3b3cca08f6e94bba9cc409520078c35088d
   
 https://github.com/perl6/specs/commit/126dd3b3cca08f6e94bba9cc409520078c35088d
   Author: Elizabeth Mattijsen l...@dijkmat.nl
   Date:   2013-09-30 (Mon, 30 Sep 2013)

   Changed paths:
 M S32-setting-library/Containers.pod

   Log Message:
   ---
   Mark .exists and .delete as deprecated, use :exists and :delete 
 instead

Re: Commensurability as Key

[yary]

I'll bite... this concept of commensurablity is not one I grasp from
your email.

functions are (sugarably) degenerate (many to 1) relations and
procedures are (sugarably) degenerate (state-transition) functions.
Perl  many other languages don't have a strong distinction between
functions  procudures (as I'm sure you know), a function is a
subroutine returning a scalar, a procedure is a subroutine with no
return value, side-effects only. A subroutine returning many values- a
parcel of containers, perhaps, or an iterator, etc- is a
many-to-many relation. I understand relational algebra from
decades of SQL work, and have seen ORM's replicate relations in object
systems with some success. What's missing for creating a relational
wonderland in perl6?

(Also: a ton of apples should _not_, in general, be added to 3000 kg
of oranges- unless I operate a refrigerated shipping line, in which
case all I care is that they are subclasses of perishables... Adding
an acre of orchard to a season in the sun might be less
commensurable, though they could both be subclasses of gifts to a
lucky winner... hmmm... what was the point again?)

Re: Are set operations needed?

[yary]

And regardless of homotopy type theory being able to supplant set theory,
with the spirit of there's more than one way to do it, set ops are still
a welcome tool.

Also in that spirit, would you like to write up a summary of HoTT
alternatives to common set ops, or post a link to a HoTT summarzing its
relation to algorithmically manipulating data? I downloaded the free PDF of
that book but I'm afraid most of it will go over my head. I can grok the
figures in http://en.wikipedia.org/wiki/Homotopy but not much more

-y


On Thu, Jul 18, 2013 at 7:16 AM, Moritz Lenz mor...@faui2k3.org wrote:

 On 07/18/2013 01:07 PM, Richard Hainsworth wrote:

 Are set operations needed in Perl6? No implementation of the perl6 set
 specification yet exists (AFAIK).


 You are wrong. Both rakudo and niecza implement significant subsets of the
 set specification.

 Cheers,
 Moritz

Re: [perl6/specs] 90fffb: short forms : @.[], %.{} and .()

[yary]

Typo: theses operator - these operators
-y


On Mon, May 6, 2013 at 10:23 AM, GitHub nore...@github.com wrote:
   Branch: refs/heads/master
   Home:   https://github.com/perl6/specs
   Commit: 90fffbad2868a1c3b3151c79a805f9834a4902e2
   
 https://github.com/perl6/specs/commit/90fffbad2868a1c3b3151c79a805f9834a4902e2
   Author: Stéphane Payrard cognomi...@gmail.com
   Date:   2013-05-06 (Mon, 06 May 2013)

   Changed paths:
 M S02-bits.pod

   Log Message:
   ---
short forms : @.[], %.{} and .()

Re: The .trans method and Least Surprise

[yary]

Speaking as a non-p6-coder proposal sounds good to me though the
spec raises some other questions.

The tr/// quote-like operator now also has a method form called
 trans(). Its argument is a list of pairs. You can use anything
 that produces a pair list:

 $str.trans( %mapping.pairs );

Does Perl 6 guarantee the order in which pairs are returned from a
hash? If not, then the following code won't always return the same
thing:

my %mapping = 'a' = 'x', 'x' = 'b'; say 'ax'.trans(%mapping);

It might say 'bb' or 'xb', depending on how the pairs are returned.
That might be considered a programmer's error, but it seems
less-than-optimal that these two lines have the same result in my
somewhat dated Rakudo install:

 say 'ax'.trans(a = x, x = b)
xb
 say 'ax'.trans(x = b, a = x)
xb

- even if it is completely in accord with spec.

And since mapping is a hash, it prevents a series of transl{ations
iterations} with the same from in a single call.
trans('A..J'='0..9', 'a..z'='A..Z', 'A..J'='zyxjihcba');
- which is a contrived example that could be rewritten to avoid the
clash, but it shows the idea.

So if you're going to alter the spec, I suggest changing the method
from accepting a hash of pairs, to accepting an array of pairs.

I still really like the idea of passing 'from' = 'to' as a pair, and
think even 'subst' should accept a pair because it looks good in the
source!

Re: Not-so-smart matching (was Re: How to make a new operator.)

[yary]

I also like agreement, conformance... In a situation like this, I
reach for a thesaurus- very useful when looking for just the right
name for a variable/method name/way to describe a concept. Here's a
grab bag to start with:

accord, agree, conformance, conformation, conformity, congruence,
congruity, consensus, consonance, correspondence, harmony, unison
agree, fit, correspond, compeer, meet, gibe, pair, mate, twin, cope with, touch

Fit, correspond, congruity, harmonize seem like other good
descriptions for the concept. Fit is especially good due to its
brevity, and congruence is good due to the use of ~~ as the smartmatch
aka congruence/fitness/agreement/harmonizing/correspondence/conformance
operator.

(Bikeshed?)

-y



On Sun, Mar 25, 2012 at 12:35 AM, David Green david.gr...@telus.net wrote:
 On 2012-March-21, at 6:38 pm, Daniel Carrera wrote:
 The idea of smart-matching a function just doesn't quite fit with my brain. 
 I can memorize the fact that smart-matching 7 and foo means evaluating 
 foo(7) and seeing if the value is true, but I can't say I understand it.

 Maybe it just needs a better name.  Match implies that two (or more) things 
 are being compared against each other, and that's how smart-matching started 
 out, but it's been generalised beyond that.  The underlying .ACCEPTS method 
 suggests acceptance... but that's too broad (a function can accept args 
 without returning true).  Agreement fits, in the sense of that [food] 
 agrees with me, but I think it suggests equality a bit too strongly.  
 Accordance?  Conformance?  Validation?  That seems a good match (ahem) 
 for the concept: ~~ checks whether some value is valid (or desired?) 
 according to certain criteria.  The obvious way to validate some value 
 against a simple string or number is to compare them; or against a pattern, 
 to see if the value matches; but given a function, you check the value by 
 passing it to the function and seeing whether it says yea or nay.

 I'm not sure validation or validity is the best name, but it conforms 
 better to what smart-matching does.  Or conformance  Hm.  But 
 terminology that sets up the appropriate expectations is a good thing.


 -David

Re: Setting private attributes during object build

[yary]

On 02/02/2012 07:40 AM, Damian Conway wrote:
 My point was that I don't want the named arguments that BUILD can take
 to be restricted to only the names of public attributes...which was, I
 thought, yary's complaint when writing...

Actually, that *was* one of my complaints, but I was mistaken on that point.

~/rakudo $ perl6
 class A{has $.b; has $!c; submethod BUILD(:$b,:$c,:$x){say b=$b c=$c x=$x}}
 A.new(b=4,c=5,x=6)
b=4 c=5 x=6


If the complaint is that yary wanted to pass positional args to a
constructor, then I have no problem with having to write one's own
non-standard new() method to achieve that.

Agreed on that too.

You could break my post down into a few distinct complaints. Moritz
distilled the one that matters the most to me, and I'll quote his
first post in full-

The current approach is violating the DRY principle. When you write a
.new method that wants to initialize private attributes, you have to
repeat all their names again in the signature of your BUILD submethod:

class A {
   has ($!x, $!y, $!z);
   method new($x, $y, $z) { self.bless(*, :$x, :$y, :$z) }
   submethod BUILD(:$!x, :$!y, :$!z) { } # is this repetition really needed?
}

It also means that private attributes are less convenient to work with
than those with accessors, which IMHO is a not signal in the right
direction.

And then Moritz expands on that a bit in a later post.


Damian:
The whole point of having BUILD() is to separate allocation
 concerns from initialization concerns.

Here's where I am late to the conversation, I hadn't known that
distinction. S12 doesn't talk about the why of BUILD/BUILDALL, at
least not that detail. If BUILD is for allocation, and new is for
initialization, then hiding private attributes from bless is forcing
the programmer to use BUILD for initialization which wasn't the
intent.

S12 says this about BUILD: Whether you write your own BUILD or not,
at the end of the BUILD, any default attribute values are implicitly
copied into any attributes that haven't otherwise been initialized.
Note that the default BUILD will only initialize public attributes;
...

And that's good, because otherwise your private attributes would not
be totally hidden.

you must write your own BUILD (as above) in order to present private
attributes as part of your initialization API.

And that's not so good, because it forces BUILD to be used for
initialization, and precludes initializing private attributes anywhere
else, like a bless called from the new method.

I don't propose having blessall/new bless set attributes directly,
it will still have to call BUILDALL, so derived classes will still
work properly. If we change bless to present private attributes to
BUILDALL, then the filtering out of private attributes would move to
the default new instead.

For example, to be clear, what we have now:

 class plain{has $.b; has $!c; method say{say b=$!b 
 c=$!c}};plain.new(b=4,c=5).say
use of uninitialized value of type Any in string context
b=4 c=

 class cust{has $.b; has $!c; method 
 new(:$b,:$c){self.bless(*,b=$b,c=$c)};method say{say b=$!b c=$!c}}; 
 cust.new(b=4,c=5).say
use of uninitialized value of type Any in string context
b=4 c=

What I'd like to see:

 class plain{has $.b; has $!c; method say{say b=$!b 
 c=$!c}};plain.new(b=4,c=5).say
use of uninitialized value of type Any in string context
b=4 c=

 class cust{has $.b; has $!c; method 
 new(:$b,:$c){self.bless(*,b=$b,c=$c)};method say{say b=$!b c=$!c}}; 
 cust.new(b=4,c=5).say
b=4 c=5

-y

Re: Setting private attributes during object build

[yary]

I think I get this better now.

Currently:
Default new passes its capture (named args) to bless. Bless passes
capture (all args) to the default BUILDALLBUILD. Default BUILD
initializes only public attributes.

My thought:
Default new passes only named args matching public attributes to
bless. Bless passes those to the default BUILDALLBUILD. Default BUILD
initializes both public  private attributes presented to it by
bless.

Setting private attributes during object build

[yary]

I wrote my first perl6 over the weekend, needing some help on #perl6.
And now after finishing some lunchtime thoughts I wanted to post here
on my main sticking point.

If one wants to set a private attribute, one must define a submethod
BUILD. If one wants to use any argument in the constructor other than
a public attribute (positional OR named other than an attribute name),
one must define a method new( ... ).

And if one wants to do both, then the initialization code must be
spread between method new ( ... ) and submethod BUILD.

One fix posited on #perl6 was a blessall method that would act like
bless, but also allow setting private attributes. That would be a
solution... but... how about going all the way and allowing bless to
set private attributes? I wasn't looking when the decisions were made
about bless, and I can understand an argument about not letting
private attributes leak out. On the other hand, if it's OK for a new
blessall, why not for bless itself instead?

-y

Re: Setting private attributes during object build

[yary]

On Wed, Feb 1, 2012 at 3:24 PM, Jonathan Lang datawea...@gmail.com wrote:
 Why must we use 'submethod BUILD' instead of 'method BUILD'?
 Is it some sort of chicken-and-egg dilemma?

from S12:
Submethods are for declaring infrastructural methods that shouldn't
be inherited by subclasses, such as initializers ... only the methods
are visible to derived classes via inheritance. A submethod is called
only when a method call is dispatched directly to the current class.

It isn't chicken-and-egg, it's safety. The BUILD submethod doesn't get
used for anything other than the class it is defined in, even if that
class is derived from.

-y

Re: Setting private attributes during object build

[yary]

On Wed, Feb 1, 2012 at 5:41 PM, Carl Mäsak cma...@gmail.com wrote:
...
Getting back to the topic of the original post: I think blessall is
a bad name for what's proposed, and I don't see a fantastically large
need for that functionality. What's wrong with just defining a BUILD
submethod in the class?

Limiting settable attributes inside new feels arbitrary. It
frustrated me as a beginner. I don't have an opinion on blessall as
a concept or as a name; I do like it as a solution to having to put
object init code in different blocks.

 I also don't see a problem of having to divide initialization code
 between .new and .BUILD. They have different purposes -- .new is
 outwards-facing, receiving arguments. .BUILD is infrastructural and
 inwards-facing, building up (as the name suggests) your attributes. If
 you need to modify both these behaviors, you override both.

 // Carl

new faces outwards but it cannot help but play inwards when it calls
bless. (And if a method new does not call bless, then it isn't a
constructor.)

-y

Re: Setting private attributes during object build

[yary]

Looking back at my paltry code, what I ended up doing was having a
BUILD submethod that just listed all my attributes, private and
public, and an empty block, essentially turning bless into
blessall. Which makes submethod BUILD looks like boilerplate, a
magic invocation, repeated in my classes. Not very elegant looking.
Not horrible, just not as good as it could be IMHO.

Re: Implementations until Perl 6.0.0 released?

[yary]

Roughly speaking, will TIMTOWTDI apply to the language itself
indefinitely? = yes.

Perl 5 is a language defined by an implementation, Perl 6 is a
language defined by a syntax and documentation. While there's no
predicting what will happen, as of now it looks like there will be a
few implementations of Perl 6- there's more than one now and nothing
to stop anyone with a good idea from starting another. On the other
hand, there are a few implementations that have already gone into
hibernation.

multi vars

[yary]

From S12- which I'm just reading due to a blog post from jwrthngtn, I
haven't thought this through-
---
You can have multiple multi variables of the same name in the same
scope, and they all share the same storage location and type. These
are declared by one proto declaration at the top, in which case you
may leave the multi  implicit on the rest of the declarations in the
same scope. You might do this when you suspect you'll have multiple
declarations of the same variable name (such code might be produced by
a macro or by a code generator, for instance) and you wish to suppress
any possible warnings about redefinition.
---

Despite the danger of confusion, for the sake of being orthogonal, I'd
prefer multi vars be the same as multi subs/methods, in that they'd
have different long names referring to different things.

# Different type signatures means different long names, different
storage locations
my multi Dog $spot;
my multi Stain $spot;

# implicit typing to set each multi var
$spot = new Dog;
$spot = new Stain;

# Presuming only Dog can wag a tail this works
$spot.wag_tail;

# This fails with dispatch-like exception, presuming both Dogs and
Stains implement this
$spot.wash;

That might be helpful for polymorphic attributes.

Or it could be that the silencing warnings on redeclaring variables
should not be spelled multi, since it isn't quite the same as the
other uses of that keyword.

-y

Lists vs sets

[yary]

+1 on this
On Mon, Oct 25, 2010 at 4:56 PM, Jon Lang datawea...@gmail.com wrote:
 As for the bit about sets vs. lists: personally, I'd prefer that there
 not be quite as much difference between them as there currently is.
 That is, I'd rather sets be usable wherever lists are called for, with
 the caveat that there's no guarantee about the order in which you'll
 get the set's members; only that you'll get each member exactly once.
 The current approach is of much more limited value in programming.

I think of a list conceptually as a subclass of a set- a list is a
set, with indexing and ordering added. Implementation-wise I presume
they are quite different, since a set falls nicely into the keys of a
hash in therms of what you'd typically want to do with it.

Re: Tweaking junctions

[yary]

In general I like where this is going but need a little hand holding
here- I'm not an expert on junctions or anything perl6-

 So I'm going to go on to propose that we create a fifth class of
 Junction: the transjunction, with corresponding keyword Cevery.

It seems that by these definitions every isn't quite a junction-

every(@list)  comparision-op  value
to mean ...
   grep  * comparision-op value,  @list;

You'll need to specify but not necessarily in the same order if you
want junctive autothreading to work on every as it does with other
junctions. In which case it should probably be returning a junction
and not an ordered list.

Which reminds me, .eigenvalues strictly speaking is a set and not a
list. !eigenstates can be whatever the internal representation is...
not that I've checked the synopsis on that...

And while I like the cleanliness of the every expressions I'm still
having trouble seeing why every should behave differently from
any, all. Maybe every isn't a junction? Maybe junctions in
general need to behave a little differently when being compared
against then they do now, so the need for every goes away?

Re: 8ecf53: [Containers] split pick into pick and roll

[yary]

 The last added paragraph says (emphasis mine):

 +The default metaphor for _picking_ is that you're pulling colored
 +marbles out a bag and then putting them back. (For picking without
 replacement see Cpick instead.)
 +Rolling requires no temporary state.

 This is confusing to me. It is supposed to be describing the _roll_
 method (as evidenced by the last sentence). Why does it mention the
 default metaphor for _picking_ instead of the default metaphor of
 _rolling_?


How about,

 The default metaphor for rolling is that you're throwing
 a fair die and noting which side lands. (For picking without
 replacement see Cpick instead.)
 Rolling requires no temporary state.

-y

Re: Natural Language and Perl 6

[yary]

This is getting more and more off topic, but if you want some lojban
pasers, start at
http://www.lojban.org/tiki/tiki-index.php?page=Dictionaries,+Glossers+and+parsers

-y




On Mon, Aug 2, 2010 at 3:58 PM, Carl Mäsak cma...@gmail.com wrote:
 Jason ():
 No specific tool is best suited for natural language processing. There was
 apparently a time in which everyone thought that a formal grammar could
 clearly define any natural language, but I don't think anyone succeeded at
 creating a complete formal grammar for any language other than something
 like Esperanto.

 Even Esperanto is about on the same level of complexity as your
 regular Indo-European language. Sure, the word-formation is more
 regular, but the freedom in creating sentences with non-obvious
 antecedents and all manner of ambiguity, is just as large as in any
 national language.

 Now, had you said Lojban, I'd have believed you. :)

 // Carl

Re: Array membership test?

[yary]

On Fri, Jul 30, 2010 at 2:22 PM, Aaron Sherman a...@ajs.com wrote:
 If you really want odd, try:

  say [1,2,3].first: * === True;
 Result: 1

 and

  say [5,2,3].first: * === True;
 Result: Rakudo exits silently with no newline

Looks like a side effect of True being implemented as an enum with value=1

Re: Suggested magic for a .. b

[yary]

On Thu, Jul 29, 2010 at 5:15 AM, Leon Timmermans faw...@gmail.com wrote:
 On Thu, Jul 29, 2010 at 3:24 AM, Darren Duncan dar...@darrenduncan.net 
 wrote:
 Some possible examples of customization:

  $foo ~~ $a..$b :QuuxNationality  # just affects this one test

 I like that

  $bar = 'hello' :QuuxNationality  # applies anywhere the Str value is used


 What if you compare a QuuxNationality Str with a FooNationality Str?
 That should blow up. Also it can lead to action at a distance. I don't
 think that's the way to go.

I think it's an elegant use of encapsulation- keeping a string's
locale with the string. If the you want to compare two strings with
different collations, either-
 $foo ~~ $a..$b :QuuxNationality  # override the locales for this test
or
  $foo ~~ $a..$b # Perl warns about conflict, and falls back to its default

-y

Re: Array membership test?

[yary]

On Thu, Jul 29, 2010 at 4:46 PM, Mark J. Reed markjr...@gmail.com wrote:
 $x ~~ any(@array)

I think this came up recently, and that's the way!

-y

Re: Suggested magic for a .. b

[yary]

On Wed, Jul 28, 2010 at 8:34 AM, Dave Whipp d...@dave.whipp.name wrote:
 To squint at this slightly, in the context that we already have 0...1e10 as
 a sequence generator, perhaps the semantics of iterating a range should be
 unordered -- that is,

  for 0..10 - $x { ... }

 is treated as

  for (0...10).pick(*) - $x { ... }

Makes me think about parallel operations.

for 0...10 - $x { ... } # 0 through 10 in order
for 0..10 - $x { ... } # Spawn 11 threads, $x=0 through 10 concurrently
for 10..0 - $x { ... } # A no-op
for 10...0 - $x { ... } # 10 down to 0 in order

though would a parallel batch of an anonymous block be more naturally written as
all(0...10) - $x { ... } # Spawn 11 threads

-y

Re: Suggested magic for a .. b

[yary]

 Swapping the endpoints could mean swapping inside test to outside
 test. The only thing that is needed is to swap from  to ||:

 $a .. $b # means $a = $_  $_ = $b if $a  $b
 $b .. $a # means $b = $_ || $_ = $a if $a  $b

I think that's what not, ! are for!

Re: Suggested magic for a .. b

[yary]

On Wed, Jul 28, 2010 at 2:29 PM, Aaron Sherman a...@ajs.com wrote:

 The more I look at this, the more I think .. and ... are reversed. ..
 has a very specific and narrow usage (comparing ranges) and ... is
 probably going to be the most broadly used operator in the language outside
 of quotes, commas and the basic, C-derived math and logic ops.

+1

Though it being the day before Rakudo *'s first release makes me
think, too late!

-y

Re: multi-character ranges

[yary]

On Wed, Jul 21, 2010 at 3:47 PM, Jon Lang datawea...@gmail.com wrote:
 ...  When comparing two strings, establishing an order between them is
 generally straightforward as long as both are composed of letters from
 the same alphabet and with the same case; but once you start mixing
 cases, introducing non-alphabetical characters such as spaces or
 punctuation, and/or introducing characters from other alphabets, the
 common-sense meaning of order becomes messy.

Well, there's locale considerations that can make it less
straightforward, even with the same case and alphabet. EG, in Danish,
aa comes after zz. But at least there are agreed-upon rules, even
if they are locale- specific, so your point about non-alphabetical
characters needing definition holds.

-y

Re: Suggested magic for a .. b

[yary]

On Fri, Jul 16, 2010 at 9:40 AM, Aaron Sherman a...@ajs.com wrote:
 For example:

 Ab .. Be

 defines the ranges:

 A B and b c d e

 This results in a counting sequence (with the most significant character on
 the left) as follows:

 Ab Ac Ad Ae Bb Bc Bd Be

 Currently, Rakudo produces this:

 Ab, Ac, Ad, Ae, Af, Ag, Ah, Ai, Aj, Ak, Al, Am,
 An, Ao, Ap, Aq, Ar, As, At, Au, Av, Aw, Ax, Ay,
 Az, Ba, Bb, Bc, Bd, Be

There is one case where Rakudo's current output makes more sense then
your proposal, and that's when the sequence is analogous to a range of
numbers in another base, and you don't want to start at the equivalent
of '' or end up at the equivalent of ''. But that's a less
usual case and there's a workaround. Using your method  example, Ab
.. Az, Ba .. Be would reproduce what Rakudo does now.

In general, I like it. Though it does mean that the sequence generated
incrementing Ab repeatedly will diverge from Ab .. Be after 4
iterations.

-y

Re: r31696 -[S32/Temporal] Permit day-of-month on Dates.

[yary]

On Thu, Jul 15, 2010 at 9:21 AM, Mark J. Reed markjr...@gmail.com wrote:
 By analogy, I'd say week-of-year should work as well.

Oof, is there a generally accepted for numbering weeks within a year?
A month's boundaries' always coincides with a day's boundary, but a
year only occasionally begins/ends on a week boundary. Come to think
of it, there isn't even consensus on what day of the week constitutes
a week start, even if Perl 6 has chosen a convention.

On the other hand, I won't complain about a week-of-year with a good
definition of how it handles weeks 0/1, 52/53. End user can choose to
use it or not. And I'm not too anxious to open up the whole calendar
choice can of worms.

Re: r31696 -[S32/Temporal] Permit day-of-month on Dates.

[yary]

On Thu, Jul 15, 2010 at 2:13 PM, Brandon S Allbery KF8NH
allb...@ece.cmu.edu wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 7/15/10 12:21 , Mark J. Reed wrote:
 By analogy, I'd say week-of-year should work as well.

 Wasn't the week stuff punted to a non-core module because there are too many
 differences in how it's handled (week starts on Sunday in the US and Israel
 and Monday elsewhere, differing notions of what first week of the year
 means, etc.)

I had the same thought but as Mark pointed out, there is an ISO
standard for numbering weeks within a year, which is also implemented
by Unix-y systems. So that portion is defensible.

-y

Re: r31630 -S02 : add initial formats for Blob (or Buf) literals

[yary]

On Sun, Jul 11, 2010 at 6:11 PM, Darren Duncan dar...@darrenduncan.net wrote:
...

 There is also still the need to cover something that looks like a list of
 integers, for the general case of a Blob/Buf literal, and yet it should have
 an appearance more like that of a scalar/number/string/etc than of an
 array/etc.

 Any thoughts on this?

We could allow separator characters within the literal, such as white
space plus [[,.;:]] - and/or allow adjacent Blobs to concatenate

0b'0:01;0
   1110
   1, 00,
   0:10' 0o'52, 35, 04, 37, 6' 0x'A7.0.5E'
# 0010111010001010101001110100010001110101001110100
# OR in octal 27212516421772470136
# OR in hex 5D154E88FEA705E
# OR in decimal 419209598145818718

Re: Filesystems and files [Was: Re: The obligation of free stuff: Google Storage]

[yary]

Sounds like a sound generalization to make.

bikeshedding
On Wed, Jun 30, 2010 at 1:29 AM, Richard Hainsworth
rich...@rusrating.ru wrote:
 This then means that there is an implicit
 $*FS.connect();
 that makes the local system available to the program.

mount is the jargon to make a filesystem available, looking
backwards, though perhaps connect is more accurate going forwards.
/bikeshedding

-y

Re: Perl 6 in non-English languages

[yary]

Reminds me of an article of yore from The Perl Journal Localizing
Your Perl Programs http://interglacial.com/tpj/13/ which discusses
the reasoning behind Locale::Maketext

the point of which is that the values you're looking up should be
able to be functions, to handle some edge cases where nothing else
will do. That module isn't exactly what Darren is looking for since
the keys are English strings with a little meta-language mixed in, but
the rest of it is worth referencing.

Re: Perl 6 in non-English languages

[yary]

If Perl 5 can support
Lingua::Romana::Perligatahttp://www.csse.monash.edu.au/%7Edamian/papers/HTML/Perligata.htmland
let you type 

benedictum factori sic mori cis classum.

instead of

bless sub{die}, $class;

then Perl 6 should be able to do it even better. I think it would be
implemented through a set of macros. Unfortunately at the moment, the Perl 6
implementation that is the most advanced at the moment, Rakudo, does not
support macros. (I'm not sure about Sprixel, Mildew, etc). So while the
language specification would make it possible to use a different natural
language as a base, it can't be implemented by the most natural method.

Re: r31054 -[S03] suggestions from dataweaver++

[yary]

And while we're at it with expanding examples, can we use string
concatenation instead of addition? It makes following what's happening
easier.

eg, +1 on that prior post.

-y

Re: Temporal.pod truncate

[yary]

===
indeed truncating to any day of the week can be implemented by user
trivially by adding/subtracting a constant number of days from the
Monday returned.


No, it's not a constant.

$sun = DateTime.new('2010-04-11').trunc( :tosunday )   # 2010-04-11
$mon = DateTime.new('2010-04-11').trunc( :tomonday )   # 2010-04-05
$sun - $mon ==  6 days

$sun = DateTime.new('2010-04-12').trunc( :tosunday )   # 2010-04-11
$mon = DateTime.new('2010-04-12').trunc( :tomonday )   # 2010-04-12
$sun - $mon == -1 day
===
You're not understanding me right- the addition  subtraction have to
happen twice. (Ever had to truncate to an arbitrary multiple of 10 for
example?)

$sunday =DateTime.new(date_in_question+1 day).trunc( :tomonday) - 1 day

Re: r30369 - docs/Perl6/Spec/S32-setting-library

[yary]

Tangentially, I'm a little surprised there isn't a random stream
factory in the core. They're useful for reproducible testing. With a
global random number generator, even if you seed it, another module
can call rand and alter the sequence you get from your rand calls.
I think something like srand that returns a pseudo-random iterator
would be useful.

Re: underscores vs hyphens (was Re: A new era for Temporal)

[yary]

On Sat, Apr 10, 2010 at 4:53 PM, John Siracusa sirac...@gmail.com wrote:
 I'm not sure if the intersection of people who speak English and
 people who program is better or worse than average when it comes to
 grammar, but I do know (from editing my share of writing) that the
 average is very bad and, further, that many programmers do not speak
 English as a first language, or at all.

Adjectives and nouns aren't English-only. So Damian's proposal is
multi-culti. One could argue that Perl's identifiers, keywords, etc
are based on English so that it is more difficult for a non-English
speaker to discern why underscore is used in some places and hyphens
in other. The solution to that would be rote memorization of method
names, including _ and - in the spelling. Not ideal, but most
likely what many English speaking programmers would do too. And would
cuss over.

Re: Temporal.pod truncate

[yary]

On Thu, Apr 8, 2010 at 7:26 PM, Mark J. Reed markjr...@gmail.com wrote:
 I think that :toweek should stay as-is; it truncates to whatever the .week
 method returns, and that's Monday-based. It would be too inconsistent for it
 to do anything else.   Asking for the latest prior Sunday or any other
 weekday is a useful function, but it doesn't really have anything to do with
 'truncation'.

indeed truncating to any day of the week can be implemented by user
trivially by adding/subtracting a constant number of days from the
Monday returned.

 I do think that an unchecked version of the setters is called for, one
 that silently converts out-of-range values rather than throwing an
 exception.  That's not an easy thing to implement outside of the library
 without duplicating all the range-checking code.

Would it be unreasonably hackish to get a converted from out-of-range
date out of the exception?

Re: r30346 - docs/Perl6/Spec/S32-setting-library

[yary]

On Thu, Apr 8, 2010 at 2:31 PM,  pugs-comm...@feather.perl6.nl wrote:
 +month (for example April 31st) or in that non-leap year (for example February
 +29th 1996).

1996 *was* a leap year! Use 2006 (or 2010, or... etc) if you want a
Feb with 28 days.

Re: A common and useful thing that doesn't appear to be easy in Perl 6

[yary]

2010/4/6 Larry Wall la...@wall.org:
    Set(Read | Write)   # bogus, R|W is really 3 sets, R, W, and RW!
    Set(Read  Write)   # okay, can only represent RW

Set(A | B) doesn't seem so bogus to me, if what you want is the power
set- not the original posters intent, but reasonable in other
contexts. Though it's not quite the power set of A,B since it omits
the empty set.

Still, I wonder if special-casing passing a junction to a set is
helpful. Why write Set (A  B) when you mean Set(A,B), and what if you
want a set of junctions, e.g. Set(AB, B|C)?

Re: One-pass parsing and forward type references

[yary]

A slight digression on a point of fact-

On Mon, Feb 1, 2010 at 9:32 AM, Larry Wall la...@wall.org wrote:
...
 You are correct that the one-pass parsing is non-negotiable; this is
 how humans think, even when dealing with unknown names.

It's common for people to read a passage twice when encountering
something unfamiliar. That's on the large level. And even on the small
level of reading for the first time, people don't read completely
linearly, skilled readers make regressions back to material already
read about 15 percent of the time. -
http://en.wikipedia.org/wiki/Eye_movement_in_language_reading (and I
read about that elsewhere years ago, wikipedia happens to be the most
convenient reference.)

I'm not arguing against 1-pass parsing for Perl6, just reminding that
humans are complicated. And Larry's quote is how humans think
whereas the research on eye jumps is about how humans read which are
not exactly the same...

-y

Re: Custom errors on subsets?

[yary]

On Mon, Jan 4, 2010 at 5:15 AM, Ovid
publiustemp-perl6langua...@yahoo.com wrote:
 Given this code:

subset Filename of Str where { $_ ~~ :f };

sub foo (Filename $name) {
say Houston, we have a filename: $name;
}
...
 Obviously the error message can use some work, but how would I customize that 
 error message (assuming such will be possible in the future)?  Clearly there 
 will be many cases where a custom error message for constraint failure could 
 make life much easier for developers.


How about
multi sub foo(Any $name) { die Houston, we have a major malfunction.}

-y

Re: Comments on S32/Numeric#Complex

[yary]

 At 00:15 +0100 12/17/09, Moritz Lenz wrote:
Not quite, .abs returns one of the polar coordinates (the magnitude), so
only a method is missing that returns the angle.

Any ideas for a good name?

Would a method called phi with a unicode synonym φ be too obtuse?

-y

Re: r29326 - docs/Perl6/Spec/S32-setting-library

[yary]

On Fri, Dec 11, 2009 at 12:31 PM,  pugs-comm...@feather.perl6.nl wrote:
...
 -It is a compiler error to use a bare Cprint without arguments.
 +The compiler will warn you if use a bare Cprint without arguments.
  (However, it's fine if you have an explicit argument list that evaluates to
  the empty list at runtime.)

 +    print;             # warns
 +    if $_ { print }    # warns
 +    if $_ { print() }  # ok, but does nothing
 +    if $_ { print () } # ok, but does nothing

What's the reasoning behind not using older perl convention of print
w/no args becoming print $_ ?

I understand that this question is probably about six years late!

Re: Language status

[yary]

 I'm looking forward to Perl 6, and I'm looking into the spec right
 now, since that to me is the important bit of a language (I know,
 I'm bizarre).

Not at all bizarre, P6 language spec development is the most important
bit going on in the language right now. Well, that plus all the
interesting implementations clarifying how it works  where it works 
where it doesn't work  making it work!

 I see at http://feather.perl6.nl/syn/
That site looks like an up-to-date mirror of the spec as it exists in
the repository, so it's a good place to browse.

that a lot of
 the language spec is still under development, and some bits still
 aren't written (or drafts are available, but not on that page). I'm
 particularly interested in those - what information is available on
 them?

This list and the #perl6 irc channel, plus just a week ago we started
getting weekly recaps-
http://lith-ology.blogspot.com/2009/12/seven-days-between-parrot-and-camel.html

-y

Re: r28597 - docs/Perl6/Spec/S32-setting-library

[yary]

...
 Also, the domain should define how to compare objects and could provide
 details about whether the set is finite, countable or uncountable.
...

Sounds like a role Domain that provides methods (off the top of my head)-

ordering - returns Nil if the domain is unordered, or a method
implementing cmp if it is ordered

succ, pred- returns Nil if the domain is uncountable, or method
implementing next item, prior item if countable.

count - returns Inf if it's an infinite domain, or count of objects if
finite. What if counting is an expensive operation? perhaps there
should also be an is_infinite method that returns true or false.

Then the .. operator can accept anything that does Domain where
ordering is non-Nil, and the ... operator can add the condition that
succ/pred are non-Nil.

Re: generality of Range

[yary]

I'm confused between using ranges to generate a lazy list and using
them as criteria to match against.

These exclude continuous (non-countable) types-

...
  2. There must be a successor function, so that given an object from
 the given domain, say a, successor(a) returns one and only one
 value from the same domain.
  3. Given b = successor(a), there is no c so that b  c  a (using the
 same operator as above).

Rationals and reals can't participate in ranges by the above, which in
a sense make sense. You can't ask for all rationals/reals between two
endpoints, or the next rational number bigger than 0. But it does
make sense to ask is $x between 0 and 1 exclusive?

There was a big discussion about this on the list recently but I don't
recall the resolutions.

And in Darren's example, could one declare a comparator and successor
operator for lists, and then get the example to produce ['Foo', 18],
['Foo', 19], ['Foo', 20], ['Foo', 21], ['Foo', 22], ['Foo', 23] ?

-y

Re: S26 - The Next Generation

[yary]

On Thu, Sep 17, 2009 at 1:05 AM, Damian Conway dam...@conway.org wrote:
 Aaron Sherman asked:
...
 I'd very much like to establish that at default optimization levels for
 execution, this information is not guaranteed to be maintained past the
 creation of the AST.

 Unfortunately, it is. Perl 6 defines that Perl 6 programs can always
 access their own Pod at runtime (via $=POD). You probably can't even
 optimize the information away in the absence of any compile-time
 reference to $=POD, since there are plenty of symbolic ways to refer to
 $=POD at run-time.

Can some concept/implementation of $=POD lazyness only incur the
memory and performance hit on access?

-y

Re: Cobra Ioke Programming Languages

[yary]

Matthew Walton wrote
Yes, Perl 6 does - it is not backwards compatible with Perl 5.

That so? I thought Perl6 was supposed to recognize and execute perl5
code. That statement itself implies that perl6 and perl5 are different
languages, and I'm not too interested in arguing over semantics. I am
curious about P6 executing P5 modules/libraries- that was in the
original plans and I think it's still included in the specs- though
not sure.

On Thu, Sep 17, 2009 at 6:06 AM, Juan Madrigal jua...@mac.com wrote:
 In addition to what you mentioned I would like to be able to specifying
 whether the language is strictly typed or dynamically type in Perl6 (not
 sure if that's possible now). Would be nice to mix both in with a keyword.

In Perl6 a variable can be untyped, typed at compile time (statically
typed), or typed at run time (dynamically typed). In fact you can also
specify the implementation of the variable independently of its type,
similar to perl5's tie interface.

For a nice long list of P6 buzzwords (though perhaps a bit outdated)
look at http://dev.perl.org/perl6/faq.html

 Hopefully Catalyst will be re-written for Perl6.
I think that's a ways away. Right now there is a built-from-scratch
wiki in perl6, November, that is pushing perl6's web code-base. P6
will either get Catalyst, or something better.

Web development with Perl
 needs to be easier PHP and Ruby make it easy. I would prefer to just use
 Perl without having to hunt down CPAN modules for features that are built in
 to other languages. Mail, Sessions/Authentication, Database Connectivity
 etc... are native. Maybe the best modules should be included or a standard
 set developed for the web including Catalyst? EmbPerl is another option.

Some people are already writing web apps in Perl6 and discussing their
experience, all getting incorporated into the discussion and P6
language / library design. If you have the time to install Rakudo, and
join the November effort, then you'll have a direct influence on the
future of web development in Perl as well!

-y

Re: Cobra Ioke Programming Languages

[yary]

Perl is being actively developed for the Parrot VM. LLVM is another
interesting option and if someone or some group would like to take it
on, it would be a welcome alternate implementation.

What parts in particular of Cobra and ioke look useful to you? Looking
at Cobra's intro slide-

* Cobra is a new language (sub 1.0)
Not sure if Perl6 qualifies as a new language. It's built off of an
old language, and is backwards compatible with it. And, perl5 is
adopting pieces of perl6. On the other hand there's enough in Perl6
that's new it's easy to make the case that it is a new case.

Though newness is not something useful to coders!

* Object-oriented, imperative
This can be implemented in Perl6

*Embraces unit tests, contracts and more
This can be implemented in Perl6

*General purpose
This can be implemented in Perl6

*Runs on .NET  Mono
Not in current implementations on Perl6

*Windows, Mac, Linux, Solaris, etc.
Rakudo (Perl6 on Parrot) runs on all those platforms.

I'm being flippant there- I think if you can ask a more specific
question you'll get a better answer. Cobra looks interesting as does
Ioke. Cobra is in late-beta and Perl6 is still alpha... Ioke looks
cleaner and simpler and with the quick look through the link you
posted, I didn't see anything jump out as hard to do in Perl6- other
than run on the JVM.

-y




On Wed, Sep 16, 2009 at 8:14 PM, Juan Madrigal jua...@mac.com wrote:
 Just wanted to get some thoughts on the following languages and if any
 features from them can be implemented in Perl6:

 Cobra
 http://cobra-language.com/docs/papers-etc/Cobra-Socal-Piggies-2008-02-Slides.pdf

 http://cobra-language.com/docs/why/

 Ioke
 http://ioke.org/wiki/index.php/Guide

 Also any thoughts on implementing Perl 6 on LLVM?

 Thanks!

 Juan

Re: Cobra Ioke Programming Languages

[yary]

This is an interesting subpage under Cobra-
http://cobra-language.com/docs/quality/

it actually bears a little on recent discussions about
self-documenting code. I'm a Perl6 beginner so I'm making comments
with expectation that others will correct where I'm wrong

* Doc Strings
Perl6's vision of doc strings are more powerful than what are in Cobra

* Unit Tests
Cobra's language-level test constructs looks cleaner then Perl's
culture-level tests.

* Contracts
Hmmm, those look like a cross between assertions and unit tests... not
sure how they fit in Perl6

* Compile-time Nil Tracking
Sounds like strong-typing to me, which one can easily request in Perl6

* Assertions
Pretty sure Perl6 has'em

Re: r28196 - docs/Perl6/Spec

[yary]

This spec subtly alters the meaning of  Whereas yada used to
mean this is not yet implemented, complain if executed it now adds
but don't complain if it is a class fully implemented elsewhere.

Allowing two implementations of a class iff one of them has a yada
opens up maintenance issues. There's action at a distance, when
reading the source looking for the definition of class Foo- the
reader could be looking at one and not seeing the other. Editors and
code refactoring gets more complicated. It's too easy for two people
to edit the different class Foos without realizing there are two,
especially if they leave the yada in place in anticipation of
further editing  reviewing.

Also this spec leaves some cases unspecc'ed. Does it matter which
order the yada class and complete class are compiled, or if there
are many yada classes? Do any of the definitions in the yada class
carry over into the complete class?

Does the same rule hold for methods, subs, all other named blocks, so
we can put a yada in one to pseudo-comment it out?

-y




On Sun, Sep 6, 2009 at 11:48 PM, pugs-comm...@feather.perl6.nl wrote:
 Author: moritz
 Date: 2009-09-07 08:48:34 +0200 (Mon, 07 Sep 2009)
 New Revision: 28196

 Modified:
   docs/Perl6/Spec/S12-objects.pod
 Log:
 [S12] spec behaviour of stubbed classes

 This is a bit more general than what I had in mind first. If the implementors
 say this is too hard to do it this way, we can degrade it to allow only a 
 single
 '...' term in the body of a stubbed class.

 Modified: docs/Perl6/Spec/S12-objects.pod
 ===
 --- docs/Perl6/Spec/S12-objects.pod     2009-09-06 15:06:11 UTC (rev 28195)
 +++ docs/Perl6/Spec/S12-objects.pod     2009-09-07 06:48:34 UTC (rev 28196)
 @@ -55,6 +55,22 @@
  class is also a module, it also handles any module-oriented keywords.
  You can export subs from a class at use time, for instance.)

 +If the class body throws an exception from a literal C... (yada) term,
 +the class defintion is considered incomplete, and a second definition of
 +that class does not complain, so you can write
 +
 +    class Foo {
 +        has $!some_attr;
 +
 +        ...     # literal ... here interrrupts class definition
 +    }
 +
 +    # other code here
 +
 +    class Foo {
 +        # rest of class defintion here
 +    }
 +
  A named class declaration can occur as part of an expression, just like
  named subroutine declarations.

Re: r28196 - docs/Perl6/Spec

[yary]

I just saw the intent for this in the  split up compilation of the
setting thread- that it is useful to:
Enable a class stub syntax that allows us to declare a given symbol
 as being a valid class without having to declare the body of the
 class at that time.  For example:

 class Rat { ... };

I can agree with that so long as the yada is the only token inside
the brackets. On the other hand why not go along with C convention and
allow

class Rat;

to pre-declare a class, or p5 convention

use class 'Rat';

-y




On Mon, Sep 7, 2009 at 9:44 AM, yarynot@gmail.com wrote:
 This spec subtly alters the meaning of  Whereas yada used to
 mean this is not yet implemented, complain if executed it now adds
 but don't complain if it is a class fully implemented elsewhere.

 Allowing two implementations of a class iff one of them has a yada
 opens up maintenance issues. There's action at a distance, when
 reading the source looking for the definition of class Foo- the
 reader could be looking at one and not seeing the other. Editors and
 code refactoring gets more complicated. It's too easy for two people
 to edit the different class Foos without realizing there are two,
 especially if they leave the yada in place in anticipation of
 further editing  reviewing.

 Also this spec leaves some cases unspecc'ed. Does it matter which
 order the yada class and complete class are compiled, or if there
 are many yada classes? Do any of the definitions in the yada class
 carry over into the complete class?

 Does the same rule hold for methods, subs, all other named blocks, so
 we can put a yada in one to pseudo-comment it out?

 -y




 On Sun, Sep 6, 2009 at 11:48 PM, pugs-comm...@feather.perl6.nl wrote:
 Author: moritz
 Date: 2009-09-07 08:48:34 +0200 (Mon, 07 Sep 2009)
 New Revision: 28196

 Modified:
   docs/Perl6/Spec/S12-objects.pod
 Log:
 [S12] spec behaviour of stubbed classes

 This is a bit more general than what I had in mind first. If the implementors
 say this is too hard to do it this way, we can degrade it to allow only a 
 single
 '...' term in the body of a stubbed class.

 Modified: docs/Perl6/Spec/S12-objects.pod
 ===
 --- docs/Perl6/Spec/S12-objects.pod     2009-09-06 15:06:11 UTC (rev 28195)
 +++ docs/Perl6/Spec/S12-objects.pod     2009-09-07 06:48:34 UTC (rev 28196)
 @@ -55,6 +55,22 @@
  class is also a module, it also handles any module-oriented keywords.
  You can export subs from a class at use time, for instance.)

 +If the class body throws an exception from a literal C... (yada) term,
 +the class defintion is considered incomplete, and a second definition of
 +that class does not complain, so you can write
 +
 +    class Foo {
 +        has $!some_attr;
 +
 +        ...     # literal ... here interrrupts class definition
 +    }
 +
 +    # other code here
 +
 +    class Foo {
 +        # rest of class defintion here
 +    }
 +
  A named class declaration can occur as part of an expression, just like
  named subroutine declarations.

Re: Parameter binding

[yary]

On Sat, Jul 25, 2009 at 2:04 PM, Patrick R. Michaudpmich...@pobox.com wrote:
 On Thu, Jul 23, 2009 at 05:56:31PM +0200, TSa wrote:
 Hmm, it seems to be the case that the binding is defined to be a
 readonly binding to the variable. I consider this a bad thing.
 We should have my $x = 1; foo($x++,$x,$x++); to call foo(1,2,2)
 and not foo(1,3,2) or even foo(2,3,1). The capture creation for
 the foo call should be strictly left to right and capturing the
 value at that moment.

 ...except that captures don't capture values -- they form references.

So we get a call to foo with three identical references to $x, which
has the value 3, or 1? That would be interesting. Or is capture
meant to be lazy, and any postincrement is only called the first time
foo dereferences that parameter? That would be very interesting! Which
I would fully support in a language whose code I never had to
maintain, but would not have to want to explain to anyone with a
straight face.

/me thinks he should hang out on #perl6 but knows he won't any time soon.

Re: Is there a way to bulky feed?

[yary]

I understand now. Given a large list, you'd like to assign chunks of
the list to an array, easily, while looping. In other words, you're
looking for a way to abbreviate this:

my $chunk_size=10_000;
my @big=''..'mnop';
for ^...@big :by $chunk_size {
  my @chu...@big[$_..($_+$chunk_size,@big.end).min]
  ... # Do stuff with @chunk
}

I'm a perl6 novice so there probably is a more elegant way to write
the above already.

From your original email, I like this idea-
for ''..'mnop' - *...@chunk[10_000] { ... } # @chunk is 1 elems or less
though I think the syntax has to change a bit. I used the *@ sigil
because chunk is slurpy, but only up to 10,000 items. Wrong on a
couple levels?

By the way, you shouldn't predeclare @chunk as you did in the
original example-
  my @a = 1 2 3 4; my @b[2]; for @a -@b {;}
the @b in the pointy block is a new declaration that shadows the
earlier my @b[2] declaration.

Re: Huffman's Log: svndate r27485

[yary]

+1 on using ln() instead of log()

Also, systems I know of that implement both log() and ln() default
ln() with base e, as perl6 does, log() uses base 10.

Re: Is there a way to bulky feed?

[yary]

On Wed, Jul 8, 2009 at 8:45 PM, Xiao Yafeng xyf.x...@gmail.com wrote:

 Any thoughts?


First let's fix the whitespace in your post so it's easier to read-

My question is: could I write below code in perl6:

# 2 loops like for @a - $b[0],$b[1] {;}
my @a = 1 2 3 4; my @b[2]; for @a -@b {;}

my @a = 1 2 3 4; my @b; for @a - @b{;}# 1 loop

# 2 loops like grep {$^a+$^b 3} == @a;
my @a = 1 2 3 4; my @b[2];
  grep(@b){say 'yes' if +...@b3} == @a;

# slurp
my @a = 1 2 3 4; grep{say 'yes' if +...@_=10} == @a;

One style point, generally a list of numbers is written as
my @a = 1..4; # list of numbers, 1 2 3 4 is a list of strings
my @a = '1'..'4' # equivalent to 1 2 3 4

As for your original question, I am not quite sure what you're asking. Do
you want a simpler way to write
for 一..四 {say $^x $^y;}
一 二
三 四
(... which assumes that unicode sequencing is working, I can't test that on
my machine!)

Or do you want something like-
for yuht! yee sahm say - $a {for eee arr -$b {say $a $b}}

Or using more memory and less looping (at least superficially!)
for 'a'..'d' X A Z {say $^p $^q};

In other words, if you can write some code that runs and tell us how you'd
like to simplify it, I might be able to answer better.

Re: XOR does not work that way.

[yary]

On Thu, Jul 2, 2009 at 8:58 AM, TSathomas.sandl...@vts-systems.de wrote:
... unless list associative operators somehow flatten the
 parens away and therefore see a single list of three values instead of
 two consecutive lists of two items.

that's exactly what list associative does, it feeds an arbitrarily
long list of values to the operator at once.

Re: XOR does not work that way.

[yary]

On Thu, Jul 2, 2009 at 9:01 AM, yarynot@gmail.com wrote:
 On Thu, Jul 2, 2009 at 8:58 AM, TSathomas.sandl...@vts-systems.de wrote:
... unless list associative operators somehow flatten the
 parens away and therefore see a single list of three values instead of
 two consecutive lists of two items.

 that's exactly what list associative does, it feeds an arbitrarily
 long list of values to the operator at once.


but it doesn't strip the parens away, sorry for hitting send before
thinking it all through.

Re: Signature for the series operator

[yary]

S02 says-

Anywhere you can use a single type you can use a set of types, for
convenience specifiable as if it were an or junction:

my Int|Str $error = $val;  # can assign if $val~~Int
or $val~~Str

so would
sub infix:...(Array|Scalar $values, Code $generator)
be kosher?

I'm with Jon, wondering about two slurpies for infix operators.