Re: Synopsis 26
On 4/12/07, Damian Conway [EMAIL PROTECTED] wrote: C our $BALANCED_BRACKETS = .. on line 22 in Parser.pm needs to be C our $BALANCED_BRACKETS; $BALANCED_BRACKETS = ... or almost all the tests have compile errors on my 5.8.8. With that fix a lot of tests still fail, here's a full report: http://sial.org/pbot/24167
Re: Synopsis 26
On 4/12/07, Ævar Arnfjörð Bjarmason [EMAIL PROTECTED] wrote: With that fix a lot of tests still fail, here's a full report: http://sial.org/pbot/24167 I updated to YAML::Syck 0.84 which made different parts of the test suite fail, see http://sial.org/pbot/24168
Re: Synopsis 26
On 3/19/07, Damian Conway [EMAIL PROTECTED] wrote: I'm hoping to get a run at finishing the Pod6 parser (in between crises), but don't hold your breath. :-( Since you seem to have something already and it's been on hiatus for quite some time could you possibly post what you have already somewhere? Maybe others (pugs people?) would be interested in improving it/writing test cases for it.
Re: List assignment question
On 11/15/06, Mark J. Reed [EMAIL PROTECTED] wrote: On 11/14/06, Vincent Foley [EMAIL PROTECTED] wrote: I was toying around with Pugs and I tried the following Perl 5 list assignment my ($a, undef, $b) = 1..3; Huh. I didn't think that worked in Perl 5, either. What am I misremembering? I distinctly recall having to do things like (my $a, undef, my $b) to avoid errors because you can't assign to undef. Maybe I'm just hallucinating. (my $x, undef, my $y) = 1 .. 3; parses to my ($x, undef, $y) = 1 .. 3 and always has as far as I know, so please share your hallucinogens with the list:)
Re: This weeks summary, part 2
On 2/18/06, The Perl 6 Summarizer [EMAIL PROTECTED] wrote: Smart match table Robin Houston had some questions/observations about the smart match table in synopsis 4. This is the table that describes how the smart match (~~) operator does its comparisons. It turns out that the table in the synopsis implies non-commutative behaviour, which came as something of a surprise. I'm surprised this thread petered out so quickly without any real resolution; it seems rather important to me. http://xrl.us/j366 That particular url isn't working.
Re: Table of Perl 6 Types
On 1/12/06, Dave Whipp [EMAIL PROTECTED] wrote: (perhaps this discussion belongs on p6l) It sure does;) (this reply moved to p6l) [EMAIL PROTECTED] wrote: Dave Whipp wrote: An Int is Enumerable: each value that is an Int has well defined succ and pred values. Conversely, a Real does not -- and so arguably should not support the ++ and -- operators. Amonst other differences, a Range[Real] is an infinite set, whereas a Range[Int] has a finite cardinality. ++ and -- aren't meant to increment or decrement to the next/last value in the set, they're increment or decrement by one (see perlop). I can see your point about them not making sense for Real since it's not an enumerable set like integers but I don't think it would be in the spirit of DWIM ... Imagine I have a concrete type FixedPoint8_1000 that stores numbers from 0 to 1000 in an 8-bit value, and does Real. Incrementing a value stored in this type by one isn't a meaningful operation. wrt the perlop reference, we manipulate strings with ++ and --; and we're going to have enumerated types (albeit backed by intergers). I'm sort-of hoping that we'll be able to use the operators on iterators, too. I think what I'm saying is that succ/pred semantics are more general than just +/- 1; and perl6 does not need to be bound by perl5's perlop. I can't find a formal defn of autoincrement in the perl6 docs. I wouldn't see a problem with defining a Real role that has a fairly sparse set of operations. Afterall, a type that does support ++ and -- (e.g. Int, Num) could easily does Enumerable if it wants to declare that it supports them. I just meant that my Real $x = 5; # Or Num or ... say ++$x; should print 6 by default as opposed to Error: no 'next' for real value. The next/prev semantics are, and should be more general than ±1, I just think that ±1 should remain the default for reals ints.
Re: Multiple implementations of Perl 6
On 12/24/05, Andrew Savige [EMAIL PROTECTED] wrote: I'm curious to know if the Perl 6 design team fully endorse a change from the Perl 5 the (single) implementation *is* the specification model to a multiple implementations are good, m'kay, but from a single (detailed and precise) specification model. They sure do, one of the big changes in Perl 6 is that there actually is a specification, as opposed to a reference implementation that serves as the spec. If perl is behaving differently than the spec says it should perl will be changed, not the spec (as might have been the case with 6 and its documentation). There's no reason for why multiple implementations wouldn't be a good thing™. Lots of other languages have multiple implementations, why not Perl?
