Re: Meditations on a Loop

[yary]

That's an enjoyable and educational read, thanks!

There's one form under TMTOWTDI that I'd like to see, but can't figure
out myself. It's the version analogous to this perl5 snippet-

  sub odd {$_ % 2}
  say grep odd,0..6;

-where the line that filters the list mentions no variables at all,
and "$_" does its work behind the curtains.

perl6 golfers, what can you formulate- using anything you like in the
"odd" sub, not adding to the Int class, not using anything with a
sigil in the filter expression? I haven't figured out how to match
p5's brevity yet.

Re: Meditations on a Loop

[yary]

On Tue, May 26, 2009 at 1:57 PM, Patrick R. Michaud  wrote:
> On Mon, May 25, 2009 at 12:37:34PM -0700, yary wrote:
> How about...?
>
>    sub odd { ^$a % 2 }
typo. "sub odd {$^a % 2}" works (caret goes between "$" and "a")

>    say grep &odd, 0..6;
nice. I need to learn the differences between calling a sub as "odd"
vs "&odd" in p6. Haven't gotten that far in the synopses yet.

> This gets us to within one character of the p5 version.  I think
> we also have the possibility of
>
>    subset odd where { $_ % 2 }
>    say grep odd, 0..6;
>
> which is the same length as the p5 version, but afaict this
> last one doesn't seem to be working in Rakudo yet.

Nope, doesn't seem to.

I was wondering why the perl5 example didn't work in p6- $_ is a
contextual variable, so why doesn't the body of "odd" get its $_ value
from grep in something like this:
sub odd_a { $_ % 2}
sub odd_b { $*_ % 2}
sub odd_c { $CONTEXT::_ % 2 }

say grep &odd_a, 0..6
(calls "say" 7 times with an uninitialized value. Same with &odd_b, &odd_c)

Re: Unexpected behaviour with @foo.elems

[yary]

I'm a relative beginner at perl6, but pretty good with perl5 (and C
and a few others), so I read
"for 0...@foo.elems"
as saying "Give me a list with one item longer then @foo", not "give
me the indexes of @foo". I can see users being tripped up by the old
problem of "we start counting at 0 and not at 1", which is more at the
root of what you're seeing. If perl6 started at 1 then you'd write

for 1...@foo.elems -> $k { do_something($k,@foo[$k]) } # wrong in this universe
for 0..(@foo.elems-1) -> $k { do_something($k,@foo[$k]) } # works

perl4-perl5.8 or so had a variable that let you change the starting
index for arrays, so you could actually make the above work. But then
everyone who'd re-arranged their brains to start counting at 0, and
written code that has a starting index of 0, would have problems.

>for @foo.values -> $k { do_something($k,@foo[$k]) }

try @foo.keys instead!

> But I point out that the earlier code sample was given to me on IRC at
> #perl6. If one of the current developers can make that mistake, other users
> will too. I cannot say whether it makes sense to alter the language because
> of this.

Changing the meaning of "elems" to mean anything other then the number
of elements seems likely to cause even more confusion!

I seem to recall one of the synopses discussing the replacement for
p5s "$#foo" to get the last index of foo, but I don't remember where.

Re: Unexpected behaviour with @foo.elems

[yary]

> Is it still a global in Perl 6?

It's not even global in perl5.10. perldoc says:
   As of release 5 of Perl, assignment to $[ is
   treated as a compiler directive, and cannot
   influence the behavior of any other file.  (That's
   why you can only assign compile-time constants to
   it.)  Its use is highly discouraged.

   Note that, unlike other compile-time directives
   (such as strict), assignment to $[ can be seen
   from outer lexical scopes in the same file.
   However, you can use local() on it to strictly
   bind its value to a lexical block.

perl6's S28 "Special Names [DRAFT]" says under "Perl5 to Perl6 special
variable translation":
 $[  -  This feature has been removed

Re: The game of life

[yary]

If anyone wants to try tackling this, a longer APL one-liner is
referenced on the APL wikipedia page and discussed in length here:

http://catpad.net/michael/apl/

As an aside, APL was the first computer language I was exposed to.
When I was around 7 years old my aunt (who lived in Boston near MIT,
Harvard) had a computer scientist friend who gave her the "APL: A
Programming Language" book, after she bragged to him about a smart
nephew who liked typewriters... I liked all the symbols and sort of
understood a few bits of it...

Re: The game of life

[yary]

And a link explaining the shorter one-liner:

http://aplwiki.com/GameOfLife

Re: Amazing Perl 6

[yary]

Back to the question of "cool things about perl6"- after showing some
of the extended syntax and its expressiveness, put up a slide saying
"it's still Perl".

Show that much of the basics still work:
> my @x=('a' .. 'z'); @x[3,4]=qw(DeeDee Ramone);
  say @x.splice(2,4).join(',')
c,DeeDee,Ramone,f

the splice and join as methods instead of subs is different in p6 then
p5 but should still look familiar. And if that is too harsh there's

"use v5"

so one can use the old syntax, if there's a want or need to.

The real benefit/amazing thing about perl6's back-compatibility is the
ability to still use the substantial mass of code libraries in cpan-

use Catalyst;

Huge plus there!

It's good to show/remind people that their investment in perl is still
valid when they pick up perl v6. That's one of the amazing things.
IMHO, it is really cool that the perl6 specs mandate that older perl
modules will work... just as I was happy that perl 5.0 let me use my
old perl 4 packages, with single quotes instead of "::" and all...

I'd also like to help "nip in the bud" a tendency to view perl v6 as a
different language from perl v5. Along those lines, might be worth
mentioning how perl 6 is already leaking into perl 5.10+, things such
as "say", the smart-match operator "~~", and various cpan modules that
implement perl v6 features like gather/take in perl v5.

Re: The game of life

[yary]

On Thu, May 28, 2009 at 5:58 PM, John M. Dlugosz
<2nb81l...@sneakemail.com> wrote:
> I came upon a copy of "A Programming Language" in a similar way.  My Dad
> passed it on from a co-worker.  I don't recall how young I was, but it was a
> very interesting read.  Perhaps this attracts youngsters because of the
> strange letters?

That was a big part of it... I'm glad Mark posted the APL snippet
because it got me to finally read up on the language that's been at
the back of my mind. Plus it's useful for p6 language discussion. APL
(and a successor, J) may still have a few tricks to lend.

One APL feature already supported in p6 is the ability to use
operations on vectors of any dimension, even mixing dimensions.
Hyperoperators let us add two arrays easily, or multiply every element
in one array by a scalar, etc. (I haven't yet figured out
multi-dimensional arrays in Rakudo, are they implemented?)

Though I'm not quite sure that S03 covers some of the different-dimension cases.
my @table=
 (1,2,3;
  4,5,6); # is this the syntax to create 2d array?
my @row=4,0,1;
my @column=
(2;
 -1);

my @added_to_each_row = @row <<+>> @table; # is that (4,3,4 ; 8,5,7) ?
my @col_products = @column <<*>> @table; # is that (2,4,6 ; -4,-5,-6) ?

Which also brings up a small point in S09, is it OK to declare an
array with 0 elements in some directions, eg
my @month_calendar[7;5]; # seven days across, five weeks down
my @week[7;0];# one line across in the calendar. Same as @week[7]
my @Sundays[0;5]; # one line down. Different from @Sundays[5]

Another concept mentioned in the APL wiki page are reduction operators
that reduce the dimensionality of an array by one. For a
one-dimensional array, APLs and Perl6's reductions are the same- [+]
1,2,3 = 6 - run the op through all values, return a single value.

But in APL, you can reduce the addition operator on a 2-dimensional
array either by columns or by rows and get a 1-dimensional column or
row of sums. Or take a 3D array and get a rectangle of sums.
Presumably APL also lets you reduce a multi-dimensional vector down to
a grand total as well. I'm not very far in the p6 synopsis so I don't
know if that's a built-in possibility, but I didn't see it mentioned
in S03.

Less general is an APL operator (actually different ops for different
directions, IMO should be a single operator) that rotates vectors, eg
"rotate left 2" transforms 1,2,3,4,5 => 3,4,5,1,2- and it also works
for arrays of any dimension. For some reason APL has 2 (or more?)
operators for rotating vectors, depending on which direction, eg
left-right vs up-down. I'd expect that a rotate operator would take a
vector saying the direction & magnitude of the rotation. Maybe APL
does do that, maybe perl6 does too, I'm not very far in the synopses.

It's been fun reading... if you are curious start with the APL
wikipedia page http://en.wikipedia.org/wiki/APL_(programming_language)
- install fonts as needed, they're also referenced from there. Then
move on to the links posted earlier about the game of life, they do a
great job of explaining the one-liners.
http://aplwiki.com/GameOfLife - short version, one generation, more
descriptive variable names
http://catpad.net/michael/apl/ - longer version, which, instead of
using a loop, makes a string copy of the short version N times and
'eval's that.

The wiki page for J, Iverson's APL successor
(http://en.wikipedia.org/wiki/J_programming_language ) has an
educational quicksort 1-liner:
quicksort=: (($:@(<#[) , (=#[) , $:@(>#[)) ({~ ?...@#)) ^: (1<#)
which I think can be transformed into a more readable perl6 one-liner.
May try it out sometime...

J's wiki has a page of examples that makes me think, if I want to get
started in that language, there's a ton of good examples:
http://www.jsoftware.com/jwiki/Essays - enviable! One of the
programmer virtues... I'd like to see the better perl6 code collected
in a wiki too.

Anonymous multidimensional array

[yary]

How does one create an anonymous multidimensional array in p6? Not an
array of arrays or a capture of captures... I'm guessing it involves
Array.new(:shape) or something like :shape(2;2), and
that it's not yet implemented in Rakudo.

Is anonymous multidimensional array creation covered in the synopses?
Might be good to answer this explicitly in S09, 'less it's in there
and I missed it.

-y

Re: Anonymous multidimensional array

[yary]

On Mon, Jun 1, 2009 at 10:43 PM, John M. Dlugosz > And it should be an
error if dimensions other than the highest are
> unspecified.  How can it know how to shape it?  Use an explicit command to
> shape up the argument in that case.

I don't see why shape(2;*) is not a problem and shape(*;2) is a
problem for an lvalue array, either each one (lazily?) demands an even
number of elements, or they both fail. In general, multiply the size
of the known dimensions, and that's the number of elements you need to
fill up one more in the unspecified dimension direction.

I do see a problem if there's more than one unspecified dimension.
Though I suppose an array of shape(*;*) as an lvalue might be a
constraint allowing assignment only of another 2D array?

Re: Anonymous multidimensional array

[yary]

I haven't gotten deep into the shape/array specs and I need to... nonetheless

On Tue, Jun 2, 2009 at 9:55 AM, Larry Wall  wrote:
> I don't see why we shouldn't use the capture shape of the value
> by default all the time, and do linear reshaping only if the value
> comes in as a flat list.

This highlights an edge case- in my mind at least, a "flat list" has a
different shape from a one-row array. shape(*) or shape() vs
shape(*;0)? Given the above, linear reshaping should not happen when
given an explicitly-1D-shaped array on the right hand side, and that's
something that should be spelled out and included in the spec tests.
Or spell out the contradiction if I guessed wrong!

>We've gone to some pains to allow ephemeral
> shaping of values through captures, and it seems like it's good error
> checking to check the shape of the value against the shape of the
> container unless explicitly defeated.
>
> That is to say, if you erase the capture shape by putting the value
> into list context, it linearizes it, and then the container knows
> to reshape.  Otherwise the container attempts to use the value slicily.

I like this, though my comprehension is currently rather primitive.

S03- Unicode feed operator, no prefix:<=>

[yary]

I'm about halfway through reading Synopsis 3 and have a couple
comments/questions.

Is there, should there be unicode synonyms for the feed operators? eg
<== is also ⇐ ⇐LEFTWARDS DOUBLE ARROW
==> is also ⇒ ⇒RIGHTWARDS DOUBLE ARROW

I don't see as obvious candidates for <<== and ==>>, maybe LEFTWARDS ,
RIGHTWARDS TWO HEADED ARROW  ↞ and ↠. That's good in that the two
headed arrow looks like the angle brackets, but then the arrow shaft
isn't doubled, so it's more of a unicode synonym for -->>

In a different section, S03 says- "In particular, you can say things
like C<$array.'@'> and C<$fh.'='>" to get the prefix form on the
operator. Hasn't prefix:<=> gone away for reading from filehandles?

Array rotate

[yary]

I am tickled pink to see an Array "rotate" method in the settings spec
S032, as I was thinking of writing up a little discussion on the very
topic.

Has there been discussion on using array rotate on multi-dimensional
arrays? Being able to pass in a vector as the amount to rotate would
be useful. eg-

my @a = (1,2,3 ; );
@a.rotate(0,1); # rotate down, @a is now (,1,2,3)
@a.rotate(1,0); # rotate right, @a is now (2,3,1;)

@a = (1,2,3 ; );
@a.rotate(1,1); # diagonal rotate, (; 2,3,1)

@a = (1,2,3 ; );
@a.rotate(1); # dimensionless rotate- does it flatten @a?
# is @a now (2,3,1;'b','c','a'), or ('c',1,2,3,'a','b')?

Thoughts?

Multi-d array transforms (was Re: Array rotate)

[yary]

Putting this in a new thread, as I'd like to discuss it separately
from refinements to Array.rotate

On Fri, Jun 12, 2009 at 10:11 AM, Jon Lang wrote:
> With a multi-dimensional array, a number of transforms can be considered:
>
> * you can rearrange the elements along a given dimension (e.g., rotate
> and reverse).

Hmm, we have an Array.reverse already, which I think flattens a
multi-D array before reversing it. Maybe it could take an adverb (:by
?) to let you specify which dimension(s) to reverse, though I can't
think of anything satisfactory to specify an axis set. Or maybe
there's a "reflect" method on Array for reversing along an axis, or
axes.

> * you can rearrange the dimensions themselves (e.g., transpose).

Reflecting on 2 or more axes creates a transposition. Maybe it makes
sense to have a separate transpose, defined in terms of reflection.

There's still more reshaping possibilities, some of which is already easy eg

my @tall[2;8] = (1 .. 16);
# tall  (1,2; 3,4 ; 5,6; ... etc)
my @wide[8;2...@tall;
# I think wide is (1 .. 8; 9 ..16)

Re: Multi-d array transforms (was Re: Array rotate)

[yary]

I think any 1D op could be transformed to "do the right thing" on a
multidimensional array, with some sort or hyperop or reduction
transform. Rotate, reverse, even add/subtract can be told "do your
thing along this vector" and return a usefully dimensioned result.

Need to work on other things at the moment but will get back to that
thought over the weekend...

Re: Array Dimensionality

[yary]

I think this proposal goes to far in the dwimmery direction-

On Sat, Jun 13, 2009 at 12:58 PM, John M. Dlugosz<2nb81l...@sneakemail.com>
wrote:
> Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote:
>>
>> So, how do I deal with a multidim array? Well, TIMTOWTDI...
>>
>>  my @a = 1,[2,[3,4]];
>>  say @a[1][1][1];
>>  say @a[1;1;1]; # I'm not sure this is correct
>>
>>
>
> I think that it should be.  That is, multi-dim subscript is always the
same
> as chained subscripts, regardless of whether the morphology is an array
> stored as an element, or a multi-dim container, or any mixture of that as
> you drill through them.
>
> I've not written out a full formalism yet, but I've thought about it.
> The multi-dim subscript would return a sub-array if there were fewer
> parameters than dimensions, an element if exact match, and recursively
apply
> the remaining subscripts to the element if too many.
>
>
>> Or.. (I'm using the proposed capture sigil here, which has '@%a' as its
>> expanded form)
>>
>>  my ¢a = 1,(2,(3,4);
>>  say ¢a[1][1][1];
>>  say ¢a[1;1;1];
>>
>> I think that makes the semantics of the API more clear...
>>
>> daniel
>>
>>
>>
>
> The plain Array would work too, in the nested morphology:
>
>   my @a = 1,[2,[3,4]];
>
> @a has 2 elements, the second of which is type Array.
>
>   say @a[1][1][1];
>
> naturally.
>
>   say @a[1;1;1];
>
> means the same thing, intentionally.
>
>   say @a[1][1;1];
>   say @a[1;1][1];
>
> ditto.

My thought is that captures, multi-D arrays, and arrays of arrays are all
different data structures, the programmer will pick them or some mix of them
for a reason, and expect consistent access semantics. I agree that the
various types should be transparently converted when necessary, but the
dwimmery proposed on indexing could make it hard to find bugs in code
dealing with complicated data structures.

The problem comes with nested structures. Let's talk about a multi-D array,
where each element is another multi-D array. This is also an example of my
 understanding of multi-D list initialization- the specs are silent on that
other than initializing elements one at a time eg. "@md[1;0] = 4;"-
apologies for squeezing two topics into one post.

# Build it piece by piece, first using explicitly dimensioned sub-arrays
# Doesn't matter if the initialization is a list, array, capture of arrays.
The RHS is in list context which flattens a capture, and the explicit
dimension will pour them all into a 2x2 array.
my @sub1[2;2]=(99,\('a',[]; 'c'; CC) ; 88, [1,2,3]);
my @sub2[2;2]=77,[], 66,[4,5,6];
my @sub3[2;2]=(55; [], 44, [7,8,9]);
# Use slice context to retain the 2x2 shape
my @@sub4=([], 33; [10,11,12], 22);

# A single column, two high
my @sub5[1;2]=([]; [13,14,15]);

# 3 ragged rows, 1 long then 2 long then 3 long
my @sub6[3;*]=('row1'; ; );

=begin comment
3 ragged columns, first 3 high, the 2 high, then 3 high
c1a c2a c3a
c1b c2b c3b
c1c c3c
=end comment
my @sub7[*;3]=(; ; 'c3a', Nil, 'c3c'); # Perilous?

# Simulate a sparse array, set two elements
my @sub8[*;*]; @sub8[(5;6),(8;0)]=;

# Now build a multi-dimensional array, each element of which is a multi-D
array
my @a[2;2;2]=\(@@sub1; @@sub2; @@sub3; @@sub4; @@sub5; @@sub6; @@sub7;
@@sub8);

# This also builds an 8-element 3D cube. Not sure about , vs ; below
my @@b=\( \( \(@@sub1; @@sub2); \(@@sub3; @@sub4));
\(\(@@sub5; @@sub6); \(@@sub7; @@sub8)));

# Same as above, but no captures, use slices all the way. Valid?
my @@c=@@( @@( @@(@@sub1; @@sub2); @@(@@sub3; @@sub4));
@@(@@(@@sub5; @@sub6); @@(@@sub7; @@sub8)));

Returning to John's post- In this case all these accessors return different
elements-

>   say @a[1][1][1];
BB
@a[1] is accessing @a as a flat array, so that returns the 2nd element of @a
which is \('a',[]; 'c'; CC), which is then treated as a flat list by
the next [1] subscript. The 2nd element of the 2nd element of that is BB.

>say @a[1;1;1];
@sub8

>   say @a[1][1;1];
CC
@a[1] is \('a',[]; 'c'; CC) which is now treated as a multi-D array.
[1;1] asks for the lower-right corner of that 2x2 array, which is CC.

>   say @a[1;1][1];
@sub8
S09 states:
You need not specify all the dimensions; if you don't, the unspecified
dimensions are "wildcarded".
So the above becomes
@a[1;1;*][1]
@a[1;1;*] is \(@@sub7;@@sub8), 2nd element of that is @sub8

S09's "Cascaded subscripting of multidimensional arrays" says the above
"will either fail or produce the same results as the equivalent semicolon
subscripts." Following that part of the spec, it should convert to @a[1;1;1]
and still return @sub8.

But what I would really like is a "strict array mode" that would give me an
error when using a subscript dimensioned different from the array's
dimensions. I think that if an array has explicit dimensions they need to be
obeyed, with 1D access a specific allowed exception. These examples shows a
necessity for distinctly different semantics for @a[1][1][1], @a[1][1;1],
and @a[1;1;1], which conflicts with S09's "Cascaded subscripting" sect

Re: Array Dimensionality

[yary]

Apologies for the long post with mistakes in it. I'm going to try
again, biting off less.

my @g[2;2];
@g[0;0]='r0c0';
@g[0;1]='r0c1';
@g[1;0]='r1c0';
@g[1;1]='r1c1';

@g[1] is  due to S09:

Multi-dimensional arrays, on the other hand, know how to handle a
multidimensional slice, with one subslice for each dimension. You need
not specify all the dimensions; if you don't, the unspecified
dimensions are "wildcarded".

@g[1] becomes @g[1;*] which is ('r1c0', 'r1c1')
(@g[1])[1] is then 'r1c1', which is the same result as @g[1;1]

Using that logic, I can't think of a case where @a[1;1;1] means
something different from ((@a[1])[1])[1]. @a[1] will become @a[1;*;*]
producing a 2d slice of the "2nd row" plane, then we get the "2nd to
the right" column of that from the next slice, and finally the "2nd
back" element of that.

In fact I'd suggest that 'unspecified dimensions are "wildcarded"'
means we don't need the "Cascaded subscripting of multidimensional
arrays" section.

I'd still like to have an error or warning on treating a multi-D array
as an array of arrays.

Re: XOR does not work that way.

[yary]

I had a bit of a problem when first encountering xor with more than
two operands as well. It made sense after I thought about it
linguistically instead of mathematically. When speaking people often
use a string of "or"s to mean "pick one and only one of these choices,
the the exclusion of all others".

Also I suspect that perl6's linguistic interpretation of "xor" (only
one true item in list) will be more useful to programmers than a
mathematical reductionist interpretation (odd number of true items in
list).

I think a note explaining the reasoning behind perl6's behavior on
exclusive-or with >2 items ought to go in the synopsis, as it's bound
to come up again.

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.

Re: XOR does not work that way.

[yary]

On Thu, Jul 2, 2009 at 8:58 AM, TSa 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, yary wrote:
> On Thu, Jul 2, 2009 at 8:58 AM, TSa 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: Is there a way to bulky feed?

[yary]

On Wed, Jul 8, 2009 at 8:45 PM, Xiao Yafeng  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 +...@b>3} <== @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  -> $a {for  ->$b {say "$a $b"}}

Or using more memory and less looping (at least superficially!)
for 'a'..'d' X  {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: 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: Parameter binding

[yary]

On Sat, Jul 25, 2009 at 2:04 PM, Patrick R. Michaud 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: 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 Foo"s 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,  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, yary 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 Foo"s 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,  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: 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  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: S26 - The Next Generation

[yary]

On Thu, Sep 17, 2009 at 1:05 AM, Damian Conway  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  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: 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: 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: 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: r29326 - docs/Perl6/Spec/S32-setting-library

[yary]

On Fri, Dec 11, 2009 at 12:31 PM,   wrote:
...
> -It is a compiler error to use a bare C without arguments.
> +The compiler will warn you if use a bare C 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: 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: Custom errors on subsets?

[yary]

On Mon, Jan 4, 2010 at 5:15 AM, Ovid
 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: 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  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: A common and useful thing that doesn't appear to be easy in Perl 6

[yary]

2010/4/6 Larry Wall :
>    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(A&B, B|C)?

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

[yary]

On Thu, Apr 8, 2010 at 2:31 PM,   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: Temporal.pod truncate

[yary]

On Thu, Apr 8, 2010 at 7:26 PM, Mark J. Reed  wrote:
> I think that :to 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: underscores vs hyphens (was Re: A new era for Temporal)

[yary]

On Sat, Apr 10, 2010 at 4:53 PM, John Siracusa  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: 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: 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( :to )   # 2010-04-11
$mon = DateTime.new('2010-04-11').trunc( :to )   # 2010-04-05
$sun - $mon ==  6 days

$sun = DateTime.new('2010-04-12').trunc( :to )   # 2010-04-11
$mon = DateTime.new('2010-04-12').trunc( :to )   # 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( :to) - 1 day

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: Perl 6 in non-English languages

[yary]

If Perl 5 can support
Lingua::Romana::Perligataand
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: 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: Filesystems and files [Was: Re: The obligation of free stuff: Google Storage]

[yary]

Sounds like a sound generalization to make.


On Wed, Jun 30, 2010 at 1:29 AM, Richard Hainsworth
 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.


-y

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

[yary]

On Sun, Jul 11, 2010 at 6:11 PM, Darren Duncan  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: r31696 -[S32/Temporal] Permit day-of-month on Dates.

[yary]

On Thu, Jul 15, 2010 at 9:21 AM, Mark J. Reed  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
 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: Suggested magic for "a" .. "b"

[yary]

On Fri, Jul 16, 2010 at 9:40 AM, Aaron Sherman  wrote:
> For example:
>
> "Ab" .. "Be"
>
> defines the ranges:
>
>  and 
>
> This results in a counting sequence (with the most significant character on
> the left) as follows:
>
> 
>
> 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: multi-character ranges

[yary]

On Wed, Jul 21, 2010 at 3:47 PM, Jon Lang  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 Wed, Jul 28, 2010 at 8:34 AM, Dave Whipp  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  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: Suggested magic for "a" .. "b"

[yary]

On Thu, Jul 29, 2010 at 5:15 AM, Leon Timmermans  wrote:
> On Thu, Jul 29, 2010 at 3:24 AM, Darren Duncan  
> 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  wrote:
> $x ~~ any(@array)

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

-y

Re: Array membership test?

[yary]

On Fri, Jul 30, 2010 at 2:22 PM, Aaron Sherman  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: 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  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: 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 C 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 C instead.)
 Rolling requires no temporary state.

-y

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

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

>every(@list)
>to mean ...
>   grep  *  ,  @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?

Lists vs sets

[yary]

+1 on this
On Mon, Oct 25, 2010 at 4:56 PM, Jon Lang  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.

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

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.

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  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  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: 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 BUILDALL>BUILD. 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 BUILDALL>BUILD. Default BUILD
initializes both public & private attributes presented to it by
"bless".

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  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: 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!

perl6-language@perl.org

[yary]

Typo: "theses operator" -> "these operators"
-y


On Mon, May 6, 2013 at 10:23 AM, GitHub  wrote:
>   Branch: refs/heads/master
>   Home:   https://github.com/perl6/specs
>   Commit: 90fffbad2868a1c3b3151c79a805f9834a4902e2
>   
> https://github.com/perl6/specs/commit/90fffbad2868a1c3b3151c79a805f9834a4902e2
>   Author: Stéphane Payrard 
>   Date:   2013-05-06 (Mon, 06 May 2013)
>
>   Changed paths:
> M S02-bits.pod
>
>   Log Message:
>   ---
>short forms : @.[], %.{} and &.()
>
>
>

Re: [perl6/specs] e85286: [S17]: Add references to hyperops, feeds, and junc...

[yary]

The commit has a link to a paper about unifying event loops & threads
doesn't server the paper anymore. Looks like you can get it at
http://www.cis.upenn.edu/~stevez/papers/LZ06b.pdf
-y


On Thu, Jun 6, 2013 at 3:53 PM, GitHub  wrote:
>   Branch: refs/heads/master
>   Home:   https://github.com/perl6/specs
>   Commit: e85286eed75d21c9273af6da5040c82f3d48a3b6
>   
> https://github.com/perl6/specs/commit/e85286eed75d21c9273af6da5040c82f3d48a3b6
>   Author: pmichaud 
>   Date:   2013-06-06 (Thu, 06 Jun 2013)
>
>   Changed paths:
> M S17-concurrency.pod
>
>   Log Message:
>   ---
>   [S17]: Add references to hyperops, feeds, and junctions.
>
>
>

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  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: 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: [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  wrote:
>   Branch: refs/heads/master
>   Home:   https://github.com/perl6/specs
>   Commit: 126dd3b3cca08f6e94bba9cc409520078c35088d
>   
> https://github.com/perl6/specs/commit/126dd3b3cca08f6e94bba9cc409520078c35088d
>   Author: Elizabeth Mattijsen 
>   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: 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: The invocation operators .* and .+

[yary]

On Wed, Jun 17, 2015 at 1:29 PM, Aristotle Pagaltzis  wrote:
> * yary  [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: 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

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
 can represent any quadratic
root
.
Haskel has this package implementing a quadratic irrational type
,
and it can translate between those and continued fractions. ... here is a
decent intro to continued fractions
.

That's a comprehensive answer for square roots of rationals, but not
for transcendental
numbers . My math is
not so hot, but perhaps a 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

.

-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

Re: Anonymous multi-subs

[yary]

On Wed, Jun 24, 2015 at 7:17 PM, Brent Laabs  wrote:
I'll just note that you can fake anon multi subs with lexical subs like
this:

my $sub = do {
proto foo (|) { * }
multi foo (Int $x) { $x + 1 }
multi foo (Str $y) { $y ~ 'a' }

&foo;
}

say $sub("hello");

I like that, and I suspect it could be made generic (a routine that takes a
list of subs, returning a multi-sub) without too much difficulty.

The sub there is still named "foo" as attested by $sub.name, but isn't
> available under that name outside of the do block.
>

I've found named lambdas very useful when debugging (in Javascript). Having
$sub.name available is a feature as far as I'm concerned!


On Wed, Jun 24, 2015 at 5:27 PM, Jon Lang  wrote:

 Or, in the body, be able to examine the actual signature passed in and
> decide what to do based on that,  That [i]could[/i] be done using a
> given/when structure, which would be equivalent to a list of signature/body
> pairs.
>
>
That works, but it means re-doing what the dispatcher already does. Nicer
to hook into existing machinery.

Shortly after writing my last message I realized that a "*signature*, *body
*pair" is exactly a sub, and that what surprises me is that there isn't
already a constructor that returns a multi-sub, given a list of subs.

S06 says "proto is a generic wrapper around the dispatch to the multis" and
"A proto is a generic dispatcher, which any given scope with a unique
candidate list will instantiate into a dispatch routine" ... that's the
machinery to hook into. I'm thinking of them as roles or types, when really
they're attributes of Routine.

Re: Types for Perl 6: request for comments

[yary]

These two variations on Brent's work the same as the original- what subtle
differences happen by adding "anon" or "my" to the declarations?

my $sub_anon = do {
anon proto foo (|) { * }
multi foo (Int $x) { $x + 1 }
multi foo (Str $y) { $y ~ 'a' }

&foo;
}

my $sub_my = do {
my proto foo (|) { * }
my multi foo (Int $x) { $x + 1 }
my multi foo (Str $y) { $y ~ 'a' }

&foo;
}

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

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]

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]

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

On Wed, Jul 1, 2015 at 6:03 AM, Giuseppe Castagna <
g...@pps.univ-paris-diderot.fr> wrote:

> On 30/06/15 22:30, yary wrote:
>
> 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.
>
>  Indeed, nicely seen. However this solution is not modular since it
> requires the modification of an "existing" class. See the paragraph I wrote
> before the excursus in Section 3.3
>

Point taken. I'd still like to employ "don't repeat yourself" and have
ColPoint's multi-method "equal" call Point's method "equal," but I haven't
been able to get this code to work. Perl people, can you debug this example
so that the call to "$a.equal($b)" returns True in some elegant way,
meaning, not explicitly naming "equal" or "Point" in the body of ColPoint's
"multi method equal(Point $p)", nor repeating Point.equal's code either,
nor touching the the Point class in any way?

-y


#!perl6
class Point {
  has $.x is rw;
  has $.y is rw;

  method equal(Point $p) {
say "In Point.equal";
($.x==$p.x)&&($.y==$p.y)
  }
};

class ColPoint is Point {
  has Str $.c is rw;

  multi method equal(ColPoint $p) {
say "In ColPoint.equal";
($.x==$p.x)&&($.y==$p.y)&&($.c eq $p.c)
  }

  multi method equal(Point $p) {
nextsame; # want this to call Point.equal
  }
};


my Point $a = ColPoint.new(x=>2,y=>21,c=>"white");
my Point $b = Point.new(x=>2,y=>21);
say $a.equal($b); # Should say True

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

[yary]

"with", "without" look awesome.

-y

On Sat, Aug 8, 2015 at 2:38 PM, GitHub  wrote:

>   Branch: refs/heads/master
>   Home:   https://github.com/perl6/specs
>   Commit: 614b6f36e1cae4c787e378bc6ab2afa1f86de1f0
>
> https://github.com/perl6/specs/commit/614b6f36e1cae4c787e378bc6ab2afa1f86de1f0
>   Author: TimToady 
>   Date:   2015-08-08 (Sat, 08 Aug 2015)
>
>   Changed paths:
> M S04-control.pod
>
>   Log Message:
>   ---
>   doc with/without
>
>
>

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

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: It's time to use "use v6.c"

[yary]

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

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