John M. Dlugosz | 1 Jun 06:32 2009
Picon

Re: renaming or adding some operators

Brandon S. Allbery KF8NH allbery-at-ece.cmu.edu |Perl 6| wrote:
>
> ⨷ perhaps?  It only makes sense that a Unicode operator be used to 
> pull in all of Unicode.
>
Bravo.
If you can't type that, you won't find it useful!

Daniel Ruoso | 1 Jun 07:13 2009

Re: The game of life

Em Qui, 2009-05-28 às 00:26 -0500, John M. Dlugosz escreveu:
> Mark J. Reed markjreed-at-gmail.com |Perl 6| wrote:
> > Perhaps Perl 6 should not aspire to the expressiveness of APL. :)  As
> > nice as it is that you can write Conway's Life in a one-liner(*), I
> > think that a little verbosity now and then is a good thing for
> > legibility....
> > (*) life ←{↑1 ω⌵.^3 4=+/,‾1 0 1◦.ϕ⊂ω}
> So how would that translate to Perl 6?  Both as an exact translation, 
> and how to do it better in a Perl way?

I didn't try to translate it, but rather I simply tried to implement it
in a way rakudo already runs.... So... here's my shot!

<CODE>
class Game {
  # XXX: rakudo doesn't know how to initialize arrays properly yet.
  has $.seed;
  has $.width;
  has $.height;
  multi method generation(Int $generation where 0) {
    return  <at> ($.seed);
  }
  multi method generation(Int $generation) {
    my  <at> previous = self.generation($generation - 1);
    my  <at> new;
    # XXX: rakudo doesn't autovivify arrays properly yet.
     <at> new.push: [] for ^$.width;
    for ^$.width X ^$.height -> $x, $y {
      # XXX: there's an extra set of parens for rakudo
      my $value = [+] map {  <at> previous[$^i][$^j] },
(Continue reading)

Larry Wall | 1 Jun 17:49 2009
Picon

Re: Amazing Perl 6

On Sun, May 31, 2009 at 04:45:12PM -0400, Brandon S. Allbery KF8NH wrote:
> On May 29, 2009, at 15:43 , John M. Dlugosz wrote:
>> Care to try ☃ ?  That's alt-meta-hyper-doublebucky-cokebottle.
>
>
> *puzzled as to why OSX Character Map thinks that's related to 雪*

Maybe they can't tell the diffence between "snowman" and "snow"?
(By the way, if you know any 日本人 named Yuki, they probably
write their name with 雪.  Which is a really cool (no pun intended)
character--if you look at the two radicals, it basically means
precipitation you can grasp.  :)

Larry

Daniel Carrera | 1 Jun 18:34 2009

Re: CPAN -- moving forward

Parrot Raiser wrote:
> One of the common factors that has contributed to the longevity of
> Unix (in the generic sense), and the Internet, is their layered
> architectures.

+1 for layered architectures.

> If this discussion can be split into clear layers,  (what gets stored,
> where, how, &c.) it might be easier to produce results.

I feel similar. I attempted to do something like that with my wiki page, 
but that didn't work so well. Now I'm trying a new approach: I am in IRC 
working with Rakudo folk on how Rakudo is going to store modules on the 
disk. Once that is done, one can begin talking about a package format 
and an installer, and then go from there.

So far the discussion has been productive and we have some code written 
that we can experiment with. So I feel encouraged.

Daniel.

Daniel Carrera | 2 Jun 02:44 2009

Module naming conventions

Hi all,

Currently in CPAN you have modules like:

Digest::MD5
Digest::SHA
Digest::MD5::Perl
Digest::SHA::PurePerl

The difference is that the first two are implemented in C and the later 
two in Perl.

Naming issues are likely to become worse in Perl 6 when we also have 
modules that use Parrot. You might have three implementations of 
Digest::SHA, one  in Perl 6, one that uses Parrot, and one that uses C. 
Worse, you might even find a module that depends on both Parrot *and* C.

I think we might need to come up with some sort of standard naming 
convention to distinguish dependencies. Something that the *user* can 
recognize quickly when he browses CPAN. My first thought was:

P6::Digest::SHA
C::Digest::SHA
Parrot::Digest::SHA

But that does nothing for modules that require both C and Parrot (it 
sounds horrendous, but I bet *someone* will do it). And btw, this isn't 
just to help users pick the right module. The modules do need different 
names to avoid naming conflicts.

(Continue reading)

Jon Lang | 2 Jun 02:50 2009
Picon

Re: Module naming conventions

On Mon, Jun 1, 2009 at 5:44 PM, Daniel Carrera
<daniel.carrera <at> theingots.org> wrote:
> I think we might need to come up with some sort of standard naming
> convention to distinguish dependencies. Something that the *user* can
> recognize quickly when he browses CPAN.

Why do we need the dependencies to be part of the name?  Perl 6
provides a rugged versioning system for its modules; we should use it.

--

-- 
Jonathan "Dataweaver" Lang

Daniel Carrera | 2 Jun 02:56 2009

Re: Module naming conventions

Jon Lang wrote:
> On Mon, Jun 1, 2009 at 5:44 PM, Daniel Carrera
> <daniel.carrera <at> theingots.org> wrote:
>> I think we might need to come up with some sort of standard naming
>> convention to distinguish dependencies. Something that the *user* can
>> recognize quickly when he browses CPAN.
> 
> Why do we need the dependencies to be part of the name?  Perl 6
> provides a rugged versioning system for its modules; we should use it.

I read S11 and AFAICT Perl 6 only includes metadata for *versions* and 
*authority*:

     class Dog:ver<1.2.1>:auth<cpan:JRANDOM>;
     class Dog:ver<1.2.1>:auth<http://www.some.com/~jrandom>;
     class Dog:ver<1.2.1>:auth<mailto:jrandom <at> some.com>;

This has nothing to do with dependencies. There is no reason why the 
same author cannot write two variations of the same module, with 
different dependencies. In fact, I suspect that will happen often. 
Digest::SHA and Digest::SHA::PurePerl are written by the same author. He 
recommends the C version to most people, but he also wrote a Perl only 
version for people who don't have access to a C compiler.
module
Using the version or authority fields to denote dependencies is a much 
greater abuse than using the base name.

Daniel.

(Continue reading)

John M. Dlugosz | 2 Jun 02:44 2009
Picon

Re: The game of life

yary not.com-at-gmail.com |Perl 6| wrote:
>>  <http://www.dlugosz.com/Perl6/web/APL.html>
>>     
>
> The rho example is interesting, though it doesn't compile in current Rakudo.
>
> "1 2 3 ⍴¨ 10 would natively be written in Perl 6 as 10 »xx« (1,2,3)."
>
> perl6 complains about non-dwimmyness. 10 <<xx>> (1,2,3) gives
> (10),(10,10),(10,10,10) , I think that matches the rho example.
>
>   
Ah, I seem to remember something about which way the arrows point with a 
scalar.  I'll look it up.

> "So let’s implement the APL ⌿ operator which works on the columns of a matrix."
>
> I think that's something that perl6 could do better then APL. From
> what I understand, APL has some operators that work on columns and
> other similar ones that work on rows, p6 has an opportunity to take
> the direction/dimension as an argument. Which is something I'm
> thinking about...
>   
Good point.  Even infix operators can take adjectives!

Can the same effect be achieved with slices?

--John

(Continue reading)

jason switzer | 2 Jun 04:21 2009
Picon

Re: Module naming conventions

On Mon, Jun 1, 2009 at 7:50 PM, Jon Lang <dataweaver <at> gmail.com> wrote:

> On Mon, Jun 1, 2009 at 5:44 PM, Daniel Carrera
> <daniel.carrera <at> theingots.org> wrote:
> > I think we might need to come up with some sort of standard naming
> > convention to distinguish dependencies. Something that the *user* can
> > recognize quickly when he browses CPAN.
>
> Why do we need the dependencies to be part of the name?  Perl 6
> provides a rugged versioning system for its modules; we should use it.

I agree entirely with Jon. This sounds like a fruitless idea and outside the
scope of the language.

The only idea that I would give any consideration to would be to extend the
versioning metadata to allow for the user to define new metadata. That
sounds too similar to the goals of XML, but it would at least allow the
community to define what metadata is important.

Some things are best left unsaid.

-Jason "s1n" Switzer
yary | 2 Jun 05:23 2009
Picon

Anonymous multidimensional array

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 <words go in here>: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


Gmane