Re: (1,(2,3),4)[2]
Rod Adams wrote:
TSa (Thomas Sandlaß) wrote:
You mean @a = [[1,2,3]]? Which is quite what you need for multi
dimensional arrays anyway @m = [[1,2],[3,4]] and here you use
of course @m[0][1] to pull out the 2. I'm not sure if this automatically
makes the array multi-dimensional to the type system though. That is
if @m[0,1] returns 2 as well or if it returns the list (1,2) or whatever.
Is @m[0..3] valid and what does it return? And what's the type of that
return value(s)? I can imagine many things ranging from a two element
array of refs to two element arrays up to a flattened list of 4 values.
@m[0,1] is an array slice of two elements, in this case two arrayrefs
[1,2], and [3,4].
@m[0;1] is a multidim deref, referencing the 4.
@m[0..3] is valid, returning arrayref x 2, undef x 2.
I think you got these wrong. With @m = ([1,2],[3,4]) these would be
true, but with @m = [[1,2],[3,4]] we have an additional reference there.
Here @m has single array-ref, not 2 array-refs.
pugs gives this:
pugs my @m = [[1,2],[3,4]]
({ref:Array})
pugs @m[0,1]
({ref:Array}, undef)
pugs @m[0..3]
({ref:Array}, undef, undef, undef)
# @m[0;1] form doesn't work in r3723
and
pugs my @m = ([1,2],[3,4])
({ref:Array}, {ref:Array})
pugs @m[0,1]
({ref:Array}, {ref:Array})
pugs @m[0..3]
({ref:Array}, {ref:Array}, undef, undef)
--
Markus Laire
Re: (1,(2,3),4)[2]
Rod Adams wrote:
Austin Hastings wrote:
--- Rod Adams [EMAIL PROTECTED] wrote:
TSa (Thomas Sandlaß) wrote:
@m = [[1,2],[3,4]]
@m[0;1] is a multidim deref, referencing the 4.
Referencing the 2, I hope?
Doh!
Yes, the 2.
Really?
@m here has _single_ array-ref so
@m[0] returns that single array-ref - [[1,2],[3,4]]
@m[0;1] then returns array-ref [3,4]
@m[0;0] would return [1,2]
@m[0;0;1] would return 2
Double-checking with pugs: (multi-dim with ; doesn't work yet)
pugs my @m = [[1,2],[3,4]]
({ref:Array})
pugs @m[0]
({ref:Array}, {ref:Array})
pugs @m[0][1]
(3, 4)
pugs @m[0][0]
(1, 2)
pugs @m[0][0][1]
2
@m = [[1,2],[3,4]] IS NOT same as @m = ([1,2],[3,4])
pugs my @m = ([1,2],[3,4])
({ref:Array}, {ref:Array})
pugs @m[0]
(1, 2)
pugs @m[0][1]
2
--
Markus Laire
Re: (1,(2,3),4)[2]
Markus Laire wrote: Rod Adams wrote: TSa (Thomas Sandlaß) wrote: You mean @a = [[1,2,3]]? Which is quite what you need for multi dimensional arrays anyway @m = [[1,2],[3,4]] and here you use of course @m[0][1] to pull out the 2. I'm not sure if this automatically makes the array multi-dimensional to the type system though. That is if @m[0,1] returns 2 as well or if it returns the list (1,2) or whatever. Is @m[0..3] valid and what does it return? And what's the type of that return value(s)? I can imagine many things ranging from a two element array of refs to two element arrays up to a flattened list of 4 values. @m[0,1] is an array slice of two elements, in this case two arrayrefs [1,2], and [3,4]. @m[0;1] is a multidim deref, referencing the 4. @m[0..3] is valid, returning arrayref x 2, undef x 2. I think you got these wrong. With @m = ([1,2],[3,4]) these would be true, but with @m = [[1,2],[3,4]] we have an additional reference there. From S02: Array and hash variable names in scalar context automatically produce references. Since [...] produces a scalar arrayref, we end up with an arrayref one both sides of the =. Now, I see two ways it could shake down from here: 1) the lhs ref acquires the value of the rhs ref. 2) both sides perform one level of dereferencing, and the list of elements from the rhs is copied over to the lhs. Having one one side dereference and not the other makes no sense at all. Either way, I see the following as all being semantically equivalent: @m = ([1,2],[3,4]); @m = [[1,2],[3,4]]; @m = (1,2; 3,4); @m = [1,2; 3,4]; @m = list([1,2],[3,4]); @m = (); @m[0]=[1,2]; @m[1]=[3,4]; @m[] = ([1,2],[3,4]); @m == [1,2], [3,4]; @m == (1,2; 3,4); If I understand Juerd correctly, the logical extension would be to have @m = 5; be the same as: @m = list(5); Thus saying that a lhs @ forces list context on the rhs, where I think having the rhs dictate context on the rhs makes a lot more sense. Basically, I'm disagreeing with some of what Juerd has said. -- Rod Adams
Re: (1,(2,3),4)[2]
Rod Adams skribis 2005-05-26 4:15 (-0500): From S02: Array and hash variable names in scalar context automatically produce references. Since [...] produces a scalar arrayref, we end up with an arrayref one both sides of the =. No. There is no scalar context on the LHS of the assignment operator. And, assigning to a reference is impossible, as a reference is a VALUE, not a VARIABLE (container). Assigning to a reference thus makes no sense in the same way that assigning a new value to the number 42 makes no sense. It is possible with some tricks, but you really shouldn't ever want to do this. If I understand Juerd correctly, the logical extension would be to have @m = 5; be the same as: @m = list(5); The RHS of an array assignment is in list context. list is an operator that does nothing more than force list context. In this case, it is entirely redundant. But, of course, valid. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: (1,(2,3),4)[2]
Is giving = a higher precedence than , still considered A Good Thing? I'm not familiar with the reasoning behind the current situation, but I'm struggling to come up with any good reasons for keeping it. Consider the alternative: my $a, $b = 1, 2; # $b should contain 2, not 1 I read this as (my $a), ($b=1), 2; The comma separates clauses in English (and other languages). Why should it not be so in Perl? If you need parens, then use them. I believe it was Larry who said When in doubt, parenthesize. At the very least, people can bounce on them with % in vi.
Re: Syntax of using Perl5 modules?
On the migration front, when someone ports Digest.pm to Perl6, I get a free upgrade, assuming the module author was kind enough to up the version number. You are making a pretty huge assumption here that whoever has a namespace in p5 CPAN has first dibs at the P6 namespace of the same name, and that they will do a straight port over. Someone else could reimplement the module for Perl 6, or perhaps the author wants to (desperately needed in some cases)completely overhaul the module and API based on lessons learnt the first time. The problem with automatic fallback is simple that you are no longer getting two different versions of the same module, you are getting two completely different libraries, with no guarentee that the API is consistent. Automatic fallback lets changes in environment leak into the process and cause unexpected changes in program functionality, and this is BAD. The only time at which having to do nothing to load a current CPAN module will be during the transition period, before a suffucient body of Perl 6 modules have built up. In the longer run, much better to have to do something special to get the old and redundant versions of modules. Adam K
Re: Virtual methods
On Wed, 2005-05-25 at 09:11, Piers Cawley wrote:
Aaron Sherman [EMAIL PROTECTED] writes:
There are many gotchas that fall out of that. For example, you might
have a special role that overrides .print to handle structured data, so
your code says:
my Foo $obj;
given $obj {
when StructuredPrintRole {
# Someone's already taken care of it, possibly
# adding a more specialized role, so leave it
# alone.
}
default {
# Add in a boring default handler
$obj does StructuredPrintRole
}
}
$obj.print($structured_data);
Woefully, you lose [if] Foo happens to be DECLARED with
StructuredPrintRole, and it overrode print. But, if it just inherited a
print(), then it works. In other words, this code will mysteriously fail
the second someone innocently adds a print method to Foo!
Action at a distance... my head hurts.
Aaron, you do realise that that's quite obscene code don't you?
Why yes, I think that was my point. This is an unfortunate consequence
of the proposed way of mixing in functionality. If this is not what
mixins are intended for, then I guess I'm way out in the tall grass, as
I'm nearly salivating over the potential.
I mean, you're
doing a case statement based on the type of its topic,
And there's something wrong with switching on type? ... I'm sure I have
no idea what's wrong with that. As long as smart matching does the right
thing with inheritance (and S04 indicates that .does is invoked), this
is a pretty traditional way to ask a variable if it does what you
want. You could explicitly call the .can method, but as this example
shows, you don't always want to know if the method EXISTS, but if it
supports functionality that you need.
and to compound the
evils, you're changing how your topic's print method works *everywhere* simply
to get your 'special' print behaviour.
Yes, that is exactly the point. You have something that behaves like a
filehandle, and you wish to tell it to handle structured data. You do
this by first asking if it supports the appropriate interface (see S12
for how a role becomes an interface), and failing that, adding a default
implementation.
This probably looks something like:
role StructuredPrintRole {
has StructuredLayout $.sdlayout;
method print($me: [EMAIL PROTECTED]) returns Int {
$me.*SUPER::print(map:{ # A12 shorthand for
WALK[:super]::
$_ ~~ StructuredData ??
$me.structure($me.sdlayout) ::
$me;
}, @list);
}
}
So, by default you can .print to our $obj, and if you support some sort
of structured data representation, the right thing happens (even though
the normal stringification of such a value would not be the same).
You might use this for, just as an example, protocol representation of
an XImage datastructure for the X protocol. The stringification of it
probably isn't the image data -- that wouldn't be terribly useful in
general -- but for writing to an X socket, you certainly do want the
data to be represented correctly, so you'd derive a role from
StructuredPrintRole and tell it how to format X protocol data correctly.
If you must do something like this (and
call it print), then write it as a multimethod or something.
I think you're thinking in terms of REPLACING functionality. I'm
thinking in terms of AUGMENTING functionality.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: comprehensive list of perl6 rule tokens
On Tue, May 24, 2005 at 08:25:03PM -0400, Jeff 'japhy' Pinyan wrote:
I have looked through the latest
revisions of Apo05 and Syn05 (from Dec 2004) and come up with the
following list:
http://japhy.perlmonk.org/perl6/rules.txt
I'll review the list below, but it's also worthwhile to read
http://www.nntp.perl.org/group/perl.perl6.language/21120
which is Larry's latest missive on character classes, and
http://www.nntp.perl.org/group/perl.perl6.language/20985
which describes the capturing semantics (but be sure to note
the lengthy threads that follow concerning changes in the
indexing from $1, $2, ... to $0, $1, ... ).
Here's my comments on the table at http://japhy.perlmonk.org/perl6/rules.txt,
downloaded 26-May 1526 UTC:
CHAREXAMPLE IMPLDESCRIPTION
===
ab N conjunction
varN subroutine
I'm not sure that var means subroutine anymore. A05 does mention
it, but S05 does not, and I think it invites way too much confusion
with conjunctions. Consider avar($x|$y) versus a var ( $x | $y ).
But if are allowing var (and I hope we do not), then the parens are
required.
x* Y previous atom 0 or more times
x**{n..m} N previous atom n..m times
Keeping in mind that the n..m can actually be any sort of closure
(although it's not implemented that way yet in PGE). The rules
engine will generally optimize parsing and handling of n..m when
it can (e.g., when n and m are both constants).
( (x) Y capture 'x'
) Y must match opening '('
It may be worth noting that parens not only capture, they also
introduce a new scope for any nested subpattern and subrule captures.
:ignorecase N case insensitivity :i
:global N match globally :g
:continue N start scanning after previous match :c
...etc
I'm not sure these are tokens in the sense of single unit of purpose
in your original message. I think these are all adverbs, and the token
is just the initial C: at the beginning of a group.
:keepallN all rules and invoked rules remember everything
That's now :parsetree according to Damian's proposed capture rules.
commitN backtracking fails completely
cut N remove what matched up to this point from the
string
after P N we must be after the pattern P
!after P N we must NOT be after the pattern P
before P N we must be before the pattern P
!before P N we must NOT be before the pattern P
As with ':words', etc., I'm not sure that these qualify as tokens
when parsing the regex -- the tokens are actually or ! and
indicate a call to a subrule of some sort, and these are just predefined
rules. The rules parser and engine may indeed tokenize them for
optimization purposes, but I don't think the language defines them
as fundamental tokens, and someone is free to override the predefined
rules with their own. (Perhaps cut and commit cannot be overridden.)
?ws N match whitespace by :w rules
?sp N match a space character (chr 32 ONLY)
Here the token is ?, indicating a non-capturing subrule.
$rule N indirect rule
::$rulename N indirect symbolic rule
@rulesN like '@rules'
%rulesN like '%rules'
{ code } N code produces a rule
foo()N subroutine returns rule
( code ) N code must return true or backtracking ensues
Here the leading tokens are actually $, ::$, @, %, {, ,
and (, and I suspect we have ?$, ?::$, ?@, and !$, !::$,
!@, etc. counterparts. Of course, one could claim that these are
really separated as in , ?, and $ tokens, but PGE's parser currently
treats them as a unit to make it easier to jump directly into the correct
handler for what follows.
[a-z] N character class
+alphaN character class
-[a-z]N complemented character class
The tokens for character class manipulation are currently [, +,
and -, although that's not officially documented in A05 or S05 yet.
Also, ranges are now [a..z] -- an unescaped hyphen appearing in an
enumerated character class generates a warning.
+\w-[0-9] N character class arithmetic
I'm not sure that it's been decided/documented that \w, \s, etc.
can appear in character class arithmetic (although it seems like it
should).
prop:XN Unicode property match
-prop:X N complemented Unicode property match
Here prop is just a subrule (or character class) similar to
+alpha, +digit, etc. Also, note that prop:X is a
Re: comprehensive list of perl6 rule tokens
Rather than answer each message in this thread individually, I'll
try to aggregate them here. Disclaimer: These are just my
interpretations of how rules are defined; I'm not the one who
decides how they *should* be defined.
On Wed, May 25, 2005 at 10:55:59AM -0400, Jeff 'japhy' Pinyan wrote:
On May 25, Mark A. Biggar said:
Jonathan Scott Duff wrote:
On Tue, May 24, 2005 at 11:24:50PM -0400, Jeff 'japhy' Pinyan wrote:
I wish !prop X was allowed. I don't see why !... has to be confined
to zero-width assertions.
!... isn't confined to use with zero-width assertions, but !...
always acts as a zero-width assertion. In essence, since we're requiring
a negative match, nothing is consumed by that negative match.
In some senses !subrule is the same as !before subrule .
Now prop X is a character class just like +digit and so
under the new character class syntax, would probably be written
+prop X or if the white space is a problem, then maybe +prop:X
(or +prop(X) as Larry gets the colon :-), but that is a pretty
adverbial case so ':' maybe okay) with the complemented case being
-prop:X.
The whitespace itself isn't a problem, but it means that whatever
follows is parsed using rules syntax and not a string constant. Thus we
probably want prop:Lu or prop(Lu) and not prop Lu.
And to be a little pedantic in terminology, I call prop:Lu a capturing
subrule, not a character class match (although that subrule probably does
match and capture just a single character). The character class
match would be +prop:Lu or something like that. However, we do
get into a parsing issue with +prop:Lu+prop:Ll, which would probably
have to be written as +prop('Lu')+prop('Ll'), unless we treat the +
as special. (AFAIK, the :-argument form of subrule calls isn't well
defined yet -- it's only briefly mentioned/proposed in A05.)
Actually the 'prop' may be unnecessary at all, as we know
we're in the character class sub-language because we saw the '+', '-'
or '[', so we could just define the various Unicode character property
codes (I.e., Lu, Ll, Zs, etc) as pre-defined character class names just
like 'digit' or 'letter'.
I like this.
Yeah, that was going to be my next step, except that the unknowing person
might make a sub-rule of their own called, say, Zs, and then which would
take precedence? Perhaps prop:X is a good way of writing it.
Well, it works out the same as if someone creates their own digit or
alpha rule. One can always get to the built-in definition by explicit
scoping using Grammar::digit (or wherever the built-ins end up
being defined).
Pm
Re: Perl development server
Hi All! If you want access, please let me know. I will send you a temporary password by e-mail, that I expect you to change the first time you get the chance. May i have an account name nemux ? Thanks! Marco.
Re: Reductions, junctions, hashslices, and cribbage scoring
On Wed, 25 May 2005, Rob Kinyon wrote:
(This post references the discussion at
http://www.perlmonks.org/?node_id=458728, particularly dragonchild's
response at the bottom.)
For those who don't know, cribbage is a game where each player has
access to 4 cards, plus a community card. Various card combinations
score points. The one in question is when cards add up to 15. If you
have a group of cards that add up to 15, you receive 2 points. This is
for every group, so if you have a ten and 2 fives, you get 4 points.
Two tens and two fives is 8 points. Face cards are worth 10 and aces
are 1, for these purposes.
I proposed the following:
# Fifteens
$score += 2 * all( 15 == [EMAIL PROTECTED] any( 0 .. 4 ) } );
* Is this syntax legal?
I think so.
* Does it do what I want it to do?
Definitely not. It looks like you are thinking of junctions in terms of
arrays, instead of scalar quantum superpositions.
any( 0 .. 4 )
This returns a scalar junction of the five values (0,1,2,3,4).
What you want is clearly all possible subsets of 0..4. You probably
should write a coroutine to generate a lazy list of them.
@hand{ $junction }
returns a scalar junction of the five cards in the hand. Junctions
auto-thread through operators, including postcircumfixes.
[+] $junction
returns $junction, since [+] $scalar == $scalar. The individual values
auto-thread through.
15 == $junction
This returns a junction of booleans. Knowing the possible values of
@hand, all of them are false.
all( $junction )
I'm not real good with nested junctions...
2 * $junction
This returns another junction, with all elements doubled. (still zeros)
You obviously want 2 * junction.elems, but I'm not sure if junctions
support that method.
$score += $junction
Again this will make $score a junction of values. It will not add each of
the junction values to $score. You probably want something like
C $score += $junction.values but that is another indication
that you should be using arrays instead of junctions. And I'm not sure
about the object interface to junctions anyway.
* Is there another way?
Assuming you write the subset coroutine above, how about
$score +=
( subsets(0..4) == map { 2 * (15 == [+] @[EMAIL PROTECTED]) } == [+] )
~ John Williams
Re: Perl6 and support for Refactoring IDE's
Stevan Little [EMAIL PROTECTED] writes:
On May 25, 2005, at 5:39 AM, Piers Cawley wrote:
One of the 'mental apps' that's been pushing some of the things I've been
asking for in Perl 6's introspection system is a combined
refactoring/debugging/editing environment for the language.
Maybe I have been reading too much about Smalltalk meta-classes lately, but in
doing some draft ideas of the Perl6 meta-model for Pugs, I realized that given
a really solid class/metaclass introspection system and access to the
interpreter level meta-meta-classes, it would be possible to easily write a
class browser much like Smalltalk.
Yes. The application in my head looks very a Smalltalk environment. The way I
see it working is that the language itself has a bunch of minimal hooks that
get triggered by various phases of compilation etc. Your editor then becomes
something that instruments the compiler in such a way that loading a file for
editing compiles it, but the compilation process hangs populates the data
structures you need for editing. So, when you go to edit, say:
class Collection {
method inject_into ($self: $initial_value is copy, *block) {
$self.each
:{ $initial_value = block($initial_value, $_) }
return $initial_value;
}
}
You'd end up with a Class object which would have all sorts of interesting
things added to it, including collections of instance variables, class
variables, methods etc. Methods would have metadata about the environment in
which they were evaluated (so when you edit a method you could recompile it in
the correct environment), the file they're found in, their source code
(possibly attributed to allow for syntax highlighting), the resulting AST,
etc. Once you have such a rich set of metadata to hand, it becomes a simple
matter of programming to add all sorts of handy features, refactorings,
breakpoints, whatever...
The point being that you don't really need a massive amount of support from the
core language to do all this. At a pinch you can take advantage of the fact
that the grammar is replaceable and core classes are extensible (and if they're
not, you just stick them in boxes for the editor's purposes).
And to extend that to also be a refactoring browser would require the
meta-meta-class system to be able to generate and emit code, which, if we
properly model the meta-meta-classes should also be fairly simple as well.
We've got eval for that. Assuming you can do eval with arbitrary bindings (and
if necessary you can drill down to parrot for it) you just do something like:
Class.can('fred').environment.eval($freds_new_sourcecode)
Of course, if you alter a macro you're going to have to reevaluate pretty much
all the source code, but so what?
And of course all this is even simpler if the interpreter is written in Perl6
(although the cyclical nature of that can be dizzying at times).
It really doesn't have to be. It'd be nice, but not necessary. You just have to
make sure you can extend the runtime using perl. And macros already do that.
However adding debugging support to this is another matter all together, and
it
is only partially useful to the non-OO programmer.
Not that hard to be honest. The same instrumented interpreter techniques can be
used to write the debugger.
Re: comprehensive list of perl6 rule tokens
On Wed, May 25, 2005 at 08:28:11AM -0700, Mark A. Biggar wrote: Jeff 'japhy' Pinyan wrote: Yeah, that was going to be my next step, except that the unknowing person might make a sub-rule of their own called, say, Zs, and then which would take precedence? Perhaps prop:X is a good way of writing it. Well we have the same problem with someone redefining 'digit'. But character classes are their own sub-language and we may need to distinguish between Rule::digit and CharClass::digit in the syntax. Larry makes the case that character classes really are rules of a sort in http://www.nntp.perl.org/group/perl.perl6.language/21120. Essentially, since characters are no longer fixed-width entities, the distinction between character class and rule can get pretty fuzzy, and so we're probably better off not trying to force one. It may simply be that in general a character class expression like +alnum-[aeiou]+punct ends up decomposing into something like [ ![aeiou]?alnum | ?punct ] which doesn't make any assumptions about character widths. Of course, the rules engine would (eventually) be written to recognize the common compositions and character class subrules and optimize for them. Pm
Re: Reductions, junctions, hashslices, and cribbage scoring
Assuming you write the subset coroutine above, how about
$score +=
( subsets(0..4) == map { 2 * (15 == [+] @[EMAIL PROTECTED]) } == [+] )
Working on it last night and this morning, I ended up with the
following, very similar rewrite.
sub gen_idx_powerset (Int $size is copy) returns Array {
my @c = ([]);
for 0 .. $size-1 - $i {
push @c, (map { [EMAIL PROTECTED], $i] }, @c);
}
return @c;
}
# Fifteens
$score += 2 * grep {
15 == [+]( @[EMAIL PROTECTED].val )
}, gen_idx_powerset( [EMAIL PROTECTED] );
(Also available at http://www.perlmonks.org/?node_id=460666)
(I had an error in my original posting. @hand is an AoH. My original
should have hypered to .val like my second one does.)
Question: Is it possible using hypers and the like to replace the
gen_idx_powerset() sub with an inline expression? I'm not worried
about maintainability - I wanna see what the new ops can do!
Thanks,
Rob
Sets (was: Reductions, junctions, hashslices, and cribbage scoring)
On Thu, May 26, 2005 at 11:03:15AM -0600, John Williams wrote: I proposed the following: # Fifteens $score += 2 * all( 15 == [EMAIL PROTECTED] any( 0 .. 4 ) } ); * Is this syntax legal? I think so. * Does it do what I want it to do? Definitely not. First, apologies in advance for what I'm about to write: I'm going to express some thoughts/ideas below and then pretty much leave it to others to decide what (if anything) should be done with it. The continuing exchanges regarding junctions, and the ongoing tendency by newcomers to think of them and try to use them as sets, makes me feel that it might be worthwhile to define and publish a standard CSet class and operations sooner rather than later in Perl 6 development. This might reduce the tendency to confuse junctions with sets, by providing something that is more clearly a set and that has operations more closely aligned with what one is expecting. From a marketing perspective, it could reduce the initial frustration I suspect many people feel when they discover that junctions don't do the set-type things they initially thought they would, by providing something that does. It becomes natural to ask if CSet should be part of the Perl 6 core; I think that's a distinction and distraction not worrying about at this point. Clearly many people are trying to treat junctions as sets, perhaps because there's no well-understood alternative for it. Writing an alternative, even on a provisional basis, might be really helpful to people. Returning to the apology -- I recognize this is a @we ought to do X post where $Pm ~~ none(@we), but given that there are a lot of people who seem to like the notion of sets in Perl 6, I'm suggestion that anyone who wanted to take a crack at drafting a proposal or implementation would likely get lots of helpful feedback, suggestions, and contributions from people who are looking to use them. Pm
Re: Syntax of using Perl5 modules?
Adam Kennedy wrote: On the migration front, when someone ports Digest.pm to Perl6, I get a free upgrade, assuming the module author was kind enough to up the version number. You are making a pretty huge assumption here that whoever has a namespace in p5 CPAN has first dibs at the P6 namespace of the same name, and that they will do a straight port over. Someone else could reimplement the module for Perl 6, or perhaps the author wants to (desperately needed in some cases)completely overhaul the module and API based on lessons learnt the first time. The problem with automatic fallback is simple that you are no longer getting two different versions of the same module, you are getting two completely different libraries, with no guarentee that the API is consistent. Automatic fallback lets changes in environment leak into the process and cause unexpected changes in program functionality, and this is BAD. The only time at which having to do nothing to load a current CPAN module will be during the transition period, before a suffucient body of Perl 6 modules have built up. In the longer run, much better to have to do something special to get the old and redundant versions of modules. You get all those possibilities whenever you install any new version of a module you get from someone else, regardless of a p5-p6 hop. In p6, when you say use Digest;, you are specifically asking for what p6 considers the latest version. In p5, it was first match on libpath. I believe the ability to specify what versions and/or authors of the module you find permissible in p6 can completely resolve your issues. If you care about getting an exact version of a module, ask for it, and you'll get it or die. In p5, your only options were to 1) not install the new version 2) install it, and globally update your code to match, 3) give each script it's own libpath. I still think auto fallback makes sense. If you don't like it, always fully specify your use statements. See S11 for details. -- Rod Adams
Re: (1,(2,3),4)[2]
Juerd wrote: Rod Adams skribis 2005-05-26 4:15 (-0500): From S02: Array and hash variable names in scalar context automatically produce references. Since [...] produces a scalar arrayref, we end up with an arrayref one both sides of the =. No. There is no scalar context on the LHS of the assignment operator. And, assigning to a reference is impossible, as a reference is a VALUE, not a VARIABLE (container). Assigning to a reference thus makes no sense in the same way that assigning a new value to the number 42 makes no sense. It is possible with some tricks, but you really shouldn't ever want to do this. You're right. It was late, and my brain missed a few details. I saw arrayref = arrayref, and C took over. If I understand Juerd correctly, the logical extension would be to have @m = 5; be the same as: @m = list(5); The RHS of an array assignment is in list context. list is an operator that does nothing more than force list context. In this case, it is entirely redundant. But, of course, valid. Of course it works that way. Why else would there be a want() function? -- Rod Adams
$*OS and OS::* mixins
I was thinking on the drive home how to write some of the File::Spec functions in P6. I realized that it would be really neat if $*OS did one of a bunch of mixins (maybe OS::unix, OS::win32, OS::vms, etc). That way, you could multimethod the various functions, using junctions and Any to provide a default. Rob
Re: comprehensive list of perl6 rule tokens
On May 26, Patrick R. Michaud said:
On Tue, May 24, 2005 at 08:25:03PM -0400, Jeff 'japhy' Pinyan wrote:
I have looked through the latest
revisions of Apo05 and Syn05 (from Dec 2004) and come up with the
following list:
http://japhy.perlmonk.org/perl6/rules.txt
I'll review the list below, but it's also worthwhile to read
http://www.nntp.perl.org/group/perl.perl6.language/21120
which is Larry's latest missive on character classes, and
http://www.nntp.perl.org/group/perl.perl6.language/20985
which describes the capturing semantics (but be sure to note
the lengthy threads that follow concerning changes in the
indexing from $1, $2, ... to $0, $1, ... ).
I'll check them out. Right now, I'm really only concerned with syntax
rather than implementation. Perl6::Rule::Parser will only parse the rule
into a tree structure.
ab N conjunction
varN subroutine
I'm not sure that var means subroutine anymore. A05 does mention
Ok. If it goes away, I'm fine with that.
x**{n..m} N previous atom n..m times
Keeping in mind that the n..m can actually be any sort of closure
Yeah, I know.
( (x) Y capture 'x'
) Y must match opening '('
It may be worth noting that parens not only capture, they also
introduce a new scope for any nested subpattern and subrule captures.
Ok. I don't think that'll affects me right now.
:ignorecase N case insensitivity :i
:global N match globally :g
:continue N start scanning after previous match :c
...etc
I'm not sure these are tokens in the sense of single unit of purpose
in your original message. I think these are all adverbs, and the token
is just the initial C: at the beginning of a group.
I understand, but that set is particularly important to me, because as far
as I am concerned, the rule
/abc/
is the object Perl6::Rule::Parser::exact-new('abc'), whereas the rule
/:i abc/
is the object Perl6::Rule::Parser::exactf-new('abc') -- this is using
node terminology from Perl 5, where exactf means exact with case
folding.
:keepallN all rules and invoked rules remember everything
That's now :parsetree according to Damian's proposed capture rules.
Ok. I haven't seen those yet.
commit N backtracking fails completely
cut N remove what matched up to this point from the
string
after P N we must be after the pattern P
!after PN we must NOT be after the pattern P
before PN we must be before the pattern P
!before P N we must NOT be before the pattern P
As with ':words', etc., I'm not sure that these qualify as tokens
when parsing the regex -- the tokens are actually or ! and
I understand. Luckily this new syntax will enable me to abstract things
in the parser.
my $obj = $S-object(assertion = $name, $neg);
# where $name is the part after the or !
# and $neg is a boolean denoting the presence of !
Since there's no longer different prefixes for every type of assertion, I
no longer need to make specific classes of objects.
?ws N match whitespace by :w rules
?sp N match a space character (chr 32 ONLY)
Here the token is ?, indicating a non-capturing subrule.
Right.
$rule N indirect rule
::$rulename N indirect symbolic rule
@rules N like '@rules'
%rules N like '%rules'
{ code }N code produces a rule
foo() N subroutine returns rule
( code )N code must return true or backtracking ensues
Here the leading tokens are actually $, ::$, @, %, {, ,
and (, and I suspect we have ?$, ?::$, ?@, and !$, !::$,
!@, etc. counterparts.
Per your second message, [EMAIL PROTECTED] would mean !before @rules,
right?
Of course, one could claim that these are
really separated as in , ?, and $ tokens, but PGE's parser currently
treats them as a unit to make it easier to jump directly into the correct
handler for what follows.
Yes, so does mine. :)
[a-z] N character class
+alpha N character class
-[a-z] N complemented character class
The tokens for character class manipulation are currently [, +,
and -, although that's not officially documented in A05 or S05 yet.
Also, ranges are now [a..z] -- an unescaped hyphen appearing in an
enumerated character class generates a warning.
+\w-[0-9] N character class arithmetic
I'm not sure that it's been decided/documented that \w, \s, etc.
can appear in character class arithmetic (although it seems like it
should).
The new character class idiom is going to confuse me
Re: comprehensive list of perl6 rule tokens
On Thu, May 26, 2005 at 07:05:41PM -0400, Jeff 'japhy' Pinyan wrote:
Here the leading tokens are actually $, ::$, @, %, {, ,
and (, and I suspect we have ?$, ?::$, ?@, and !$, !::$,
!@, etc. counterparts.
Per your second message, [EMAIL PROTECTED] would mean !before @rules,
right?
I think so -- at least, it seems that way to me. I feel as though
I may be missing some subtle difference between the two (and if anyone
can identify one I'd really appreciate it).
And, what's the deal with RULE capturing? Does that mean I have to
write ?digit everywhere instead of digit unless I want a capture? Eh,
I guess \d exists for that reason...
That, or you could write +digit.
Pm
Re: Sets
Patrick R. Michaud wrote:
The continuing exchanges regarding junctions, and the ongoing tendency
by newcomers to think of them and try to use them as sets, makes
me feel that it might be worthwhile to define and publish a standard
CSet class and operations sooner rather than later in Perl 6
I agree. See pugs/ext/Set.
It presents a set-like interface to Junctions.
eg,
use Set;
my $low = set( 0..4 );
my $odd = set( (0..4).map:{ $_ * 2 + 1 } );
say ($low $odd).members.join(,); # 1,3
say ($low $odd).members.join(,); # 0,1,2,3,4,5,7,9
# difference - not this is not a backslash, it's U+2216
say ($low $odd).members.join(,); # 0,2,4
say ($odd $low).members.join(,); # 5,7,9
# symmetric difference - union of the above
say ($low % $odd).members.join(,); # 0,2,4,5,7,9
# test for membership
say $low 4; # true
say $low 5; # true
say $odd 4; # false
say $odd 5; # false
# set relations
say ( $low $odd ) $low; # true
Well, actually the above doesn't work yet. But there are ASCII versions
and english methods for those that like coding something that actually
works today ;).
Here's a directed graph traversal that handle cycles correctly; this is
largely why I'd like to see a common Role to all containers... so that
.values can be expected to DTRT. OTOH, maybe Maps with object keys would
miss out in this algorithm so another method name is more appropriate.
use Set;
my @stack = ($root);
my $seen = set(@stack);
while (my $item = shift @stack) {
# do something with $item
if $item.can(values) {
push @stack, $item.values.grep:{ $seen.insert($_) };
}
}
Caveats for the above probably abound, but you get the picture.
Note that the Set::Object module for Perl 5 is useful for the same thing
(assumes that $root is a ref):
use Set::Object qw(set);
use Scalar::Util qw(reftype blessed);
use Perl6::Junction qw(any);
my @stack = ($root);
my $seen = set(@stack);
while (my $item = shift @stack) {
# do something with $item
if (blessed $item and $item-can(members)) {
push @stack, grep { ref $_ $seen-insert($_) } $item-members;
}
if (reftype $item eq HASH) {
push @stack, grep { ref $_ $seen-insert($_) } values %$item;
}
elsif (reftype $item eq ARRAY) {
push @stack, grep { ref $_ $seen-insert($_) } @$item;
}
elsif (reftype $item eq any(qw(REF SCALAR)) ) {
push @stack, $$item if $seen-insert($$item);
}
}
As you can see, this sort of thing ends up an anti-design pattern.
Sam.
