deciphering infix:

[Patrick R. Michaud]

Rakudo gives some strange results when sorting a list
of mixed strings and numbers, which leads me to look
for some clarification on infix: (which S03:2866 says
that sort uses by default).   Here's the case I found
in Rakudo:

  > say ('a', 1, 'b', 2 , 'c', 3, 'd', 4).sort.perl;
  ["a", "b", "c", 1, 2, 3, 4, "d"]

After tracking it down a bit -- it's not clear what
infix: should do when given arguments of differing
types.  S03:2855 says:

Binary C is no longer the comparison operator that
forces stringification.  Use the C operator for the old Perl 5
C semantics.  The C is just like the C above except that
instead of returning C or C values it always
returns C, C, or C
(which numerify to -1, 0, or +1).

So, since C is just like C, here's the definition of C
for immutable types (S03:2829):

Binary C tests equality much like C<===> does, but does
so with "snapshot" semantics rather than "eternal" semantics.  For
top-level components of your value that are of immutable types, C
is identical in behavior to C<===>. 

And if we look at C<===>, we have (S03:2802):

Binary C<===> tests immutable type and value correspondence:
for two value types (that is, immutable types), tests whether
they are the same value (eg. C<1 === 1>); [...]
Two values are never equivalent unless they are of exactly
the same type.

This means that C< 3 === '3' > would be false, and
since C is identical to C<===> for immutable types,
C< 3 eqv '3' > would also be false.

But what to do with something like C< 3 cmp '3' >, or any 
infix: where the operands are of differing types?
Unlike C and C<===> that can simply return false for 
arguments of different types, C wants to return an
ordering.  Do we constrain C to only work on similarly-typed
operands (in which case my sort above would fail), or am I 
overlooking something obvious?

Pm

Re: Logo considerations

[Darren Duncan]

Larry Wall wrote:

On Tue, Mar 24, 2009 at 09:49:42AM -0700, Jon Lang wrote:
: 2009/3/24 Larry Wall :
: > http://www.wall.org/~larry/camelia.pdf

Not picking on you in particular, but I think there's a tendency to
go way too abstract in most of these proposals.  I want something
with gut appeal on the order of Tux.



Hence, Camelia.


I'm quite happy with Camelia being the basis for the logo for the Perl 6 
language itself.


Larry Wall wrote:
> If you guys want versions of Camelia in her "attack"
> mode, that's okay too.  :)
>
> And in fact, the >>ö<< form looks more like a Hyper Attack Butterfly
> that is about to bite your face off...  :)

Please don't.  I think the happy version is much better than any angry or 
violent version.  We want the logo to evoke happiness after all.


-- Darren Duncan

Metacharacters in character classes

[Carl Mäsak]

It started by yours truly asking impertinent questions on #perl6...

 

...and ended with a general feeling that the way metacharacters and
backwhacking work in <[ ]> character classes, is at worst inconsistent
and at best underspecified by S05.

Specifically, the following paragraphs from that spec do _not_ hold
for character classes, which are more like a sublanguage of their own:

] Unlike traditional regular expressions, Perl 6 does not require
] you to memorize an arbitrary list of metacharacters.  Instead it
] classifies characters by a simple rule.  All glyphs (graphemes)
] whose base characters are either the underscore (C<_>) or have
] a Unicode classification beginning with 'L' (i.e. letters) or 'N'
] (i.e. numbers) are always literal (i.e. self-matching) in regexes. They
] must be escaped with a C<\> to make them metasyntactic (in which
] case that single alphanumeric character is itself metasyntactic,
] but any immediately following alphanumeric character is not).
]
] All other glyphs--including whitespace--are exactly the opposite:
] they are always considered metasyntactic (i.e. non-self-matching) and
] must be escaped or quoted to make them literal.  As is traditional,
] they may be individually escaped with C<\>, but in Perl 6 they may
] be also quoted as follows.

In character classes, most 'other glyphs' mean themselves, just like
alphanumerics, with a few notable exceptions: backslash (\), closing
bracket (]) and dash (-) and whitespace still need to be backwhacked.
All other characters are treated literally, including dot (.) which is
actually used for metasyntactic purposes in character classes. In
other words, currently /<[.]>/ is legal, but /<[-]>/ is not. Which is
kinda weird, if you ask me.

See the linked #perl6 log for details.

What's the big-picture rule of thumb regarding metacharacters in
character classes?

// Carl

Camelia - Queen of Perl

[Richard Hainsworth]

Just read nearly 100 emails on Re: Logo Considerations, a whole lot in 
reverse order and repeated! Is this the result of a perl6 implementation 
of a listserver using junctions?


But I agree with Brett, Camelia is the first logo idea I really liked.

I vote we tell Camelia she has the prize she so earnestly wants - being 
the logo of Perl6.


Question to Larry:
Would Camelia prefer to be considered a Queen Bee, a Butterfly, or is 
she a junction of both?


Richard

Re: Logo considerations - 3 logos needed

[Guy Hulbert]

On Wed, 2009-25-03 at 18:06 -0700, Larry Wall wrote:
> : Here is something then:
> : http://p6.hpfamily.net/rakudo-0.png
> 
> I like Camelia at that size, though the left-right balance is off in a
> couple ways.

i was informed of that but so far this is just rescaling and
cut-and-paste

> 
> : > So let me summarize the requirements into a meta-requirement:
> : > 
> : > The new logo must make Larry at least as happy as Camelia
> does.
> : 
> : If anyone likes this and Larry is happy, I have some in-house
> artists
> : with gimp skills far superior to my own who might be persuaded to
> work
> : on it tonight.

mid-terms ... will have to put this off for a few days

> 
> Well, I don't have to be persuaded, and I'm my own in-house artist
> (well, I have Geneva too, who's just as good at that as I am--okay,
> maybe she's better--and I also bummed a certain amount of gimp advice
> from Lewis).  So anyway, I thought I'd take a crack at a 16x16
> Camelia.
> I think this does tolerable fair as a favicon:
> 
> http://www.wall.org/~larry/cameliafav.ico
> 
> To be honest, I thought I'd have to simplify her a lot more than
> turned
> out to be necessary.  Hand-crafted anti-aliasing is your friend. :)

-- 
--gh

Re: use v5 Support

[Daniel Ruoso]

Em Qua, 2009-03-25 às 23:11 -0500, jason switzer escreveu:
> S01 says that perl5 code will be supported via "use v5". Can someone confirm
> that embedded perl5 code is still required of any valid implementation?

I wouldn't think it would be a really bad idea if inline "use v5" inside
Perl 6 code to be optional for 6.0.0

> If so, how will XS code be supported?

Well, XS code certainly needs to be ran inside a perl5 interpreter.

> Will the namespace between v5 code and v6 be shared?

the definition of namespace in Perl 6 is very much different from the p5
one. In Perl5 all namespace is global... which is not the case for Perl
6, where the namespace is lexically built (of course you still have
GLOBAL::, but that's a minor issue).

So, in my head, you have the Perl 6 GLOBAL:: package as a different
thing than the p5 ::main namespace... maybe somehow we alias it as
GLOBAL::v5::main or something like that... but when you "use
Foo:from", it certainly doesn't automatically get into the
GLOBAL:: Perl 6 namespace (unless you are in GLOBAL::, of course), so
the p5 package is imported as a lexical alias in the current scope.

> Will this be accomplished by linking libperl

linking libperl is certainly the most sane way to implement such
backward compatibility. The biggest challenge is the support for
reentrancy, since p5 is not entirely stackless. the case of a p6 module
that uses a p5 module that uses a p6 module will be the most challenging
situation (since p5 recurses in the C stack in that case).

There's already a specific plan of merging the p5 runloop with SMOP, in
order to make it work:
http://www.perlfoundation.org/perl6/index.cgi?smopp5

> I want to propose another idea (that seems better to me at least). This
> sounds like a good place where a user module could create a perl5 grammar (a
> version of STD.pm). I'm not too familiar with how the perl6 STD.pm works,
> but I've heard there were efforts to attach actions to its YAML output,
> similar to how Parse::RecDescent does in perl5 to yacc-like grammars.

Having a p5 grammar implemented in Perl 6 is not that all a bad idea, to
solve the inline problem (even if using libperl to build SV* for the
variables)... but I still wonder why would someone write p5 code inlined
inside a p6 module?

daniel