Simple RegExp (Ap5) question
If spaces delimit tokens, /abc* def/ means in perl5 /abc*def/ or /(?:abc)*def/ ? Thanks Alberto -- Alberto Manuel B. Simoes Departamento de Informática - Universidade do Minho http://alfarrabio.di.uminho.pt/~albie - http://numexp.sf.net
Re: Simple RegExp (Ap5) question
On 15 Jun 2002, Alberto Manuel Brandão Simões wrote: > > If spaces delimit tokens, > > /abc* def/ means in perl5 > > /abc*def/ > or /(?:abc)*def/ ? > > Thanks > > Alberto The former.
Implementing Parse::RecDescent directives
Now that it seems that Parse::RecDescent and, ultimately,
Parse::FastDescent, will be subsumed into the Perl 6 regex/grammar system,
I've been thinking about how to implement P::RD directives such as
, and ; or features such as tracing.
I've really only thought about , but am not sure if those thoughts
are even going in the right direction, so please correct anything that
looks like nonsense.
Suppose you want a assertion that works like the
directive in P::RD, so that
becomes the same as
(and )*
There could be a two-arg version of that assumes the rightop
is the same as the leftop:
I'm not sure of the syntax to invoke rules that take more than one
argument. Maybe it would be
(I hope I'm right in assuming that arguments to rules aren't evaluated
but rather passed in literally like a kind of macro mechanism, otherwise
I don't understand how
rule not ($rx) { }
is supposed to work.)
Now, could you just do
rule leftop ($leftop, $op) {
<$leftop> [$op <$leftop>]*
}
rule leftop ($leftop, $op, $rightop) {
<$leftop> [$op <$rightop>]*
}
That is, if there are multimethods. If not, i suppose we could have
rule leftop is multimethod($leftop, $op) { ... }
rule leftop is multimethod($leftop, $op, $rightop) { ... }
Does that look like valid Perl 6 code (it's my first try to be honest)
or is it just nonsense?
Thanks
Marcel
--
We are Perl. Your table will be assimilated. Your waiter will adapt to
service us. Surrender your beer. Resistance is futile.
-- London.pm strategy aka "embrace and extend" aka "mark and sweep"
Re: Implementing Parse::RecDescent directives
On Sat, Jun 15, 2002 at 03:19:34PM +0200, Marcel Gruenauer wrote:
> Now, could you just do
>
> rule leftop ($leftop, $op) {
> <$leftop> [$op <$leftop>]*
> }
>
> rule leftop ($leftop, $op, $rightop) {
> <$leftop> [$op <$rightop>]*
> }
At the very least you should be able to do this:
rule leftop($leftop,$op;$rightop) {
$other := { (defined $rightop) ?? $rightop :: $leftop }
<$leftop> [$op <$other>]*
}
or, an ickier version:
{ my $other;
rule leftop($leftop,$op;$rightop) {
{ $other = (defined $rightop) ?? $rightop :: $leftop }
<$leftop> [$op <$other>]*
}
}
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Implementing Parse::RecDescent directives
On Sat, Jun 15, 2002 at 09:08:31AM -0500, Jonathan Scott Duff wrote:
> At the very least you should be able to do this:
>
> rule leftop($leftop,$op;$rightop) {
> $other := { (defined $rightop) ?? $rightop :: $leftop }
> <$leftop> [$op <$other>]*
> }
Or maybe
rule leftop($leftop,$op;$rightop) {
<$leftop> [$op <{ $rightop // $leftop }>]*
}
Marcel
--
We are Perl. Your table will be assimilated. Your waiter will adapt to
service us. Surrender your beer. Resistance is futile.
-- London.pm strategy aka "embrace and extend" aka "mark and sweep"
Re: Implementing Parse::RecDescent directives
On Sat, Jun 15, 2002 at 04:50:20PM +0200, Marcel Gruenauer wrote:
> On Sat, Jun 15, 2002 at 09:08:31AM -0500, Jonathan Scott Duff wrote:
>
> > At the very least you should be able to do this:
> >
> > rule leftop($leftop,$op;$rightop) {
> > $other := { (defined $rightop) ?? $rightop :: $leftop }
> > <$leftop> [$op <$other>]*
> > }
>
> Or maybe
>
> rule leftop($leftop,$op;$rightop) {
> <$leftop> [$op <{ $rightop // $leftop }>]*
> }
Indeed; I'd forgotten about //.
With all this new syntax, I can't wait until there's a perl6 I can try
it out against rather than just perl6-language.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Implementing Parse::RecDescent directives
> Now, could you just do
>
> rule leftop ($leftop, $op) {
> <$leftop> [$op <$leftop>]*
> }
>
> rule leftop ($leftop, $op, $rightop) {
> <$leftop> [$op <$rightop>]*
> }
I should hope that rules can take multiple arguments. Here's something
that made me wonder, though: the <$leftop> there is meant to call a rule.
But, that syntax -- <$whatever> -- is how you embed a regex in another
regex. So how do we know that $leftop is not a regex wanting to match
"atom"? How do we force it to be a rule call? Is it like <$leftop:>?
But back to this: If <$leftop:> is a rule call, I'd want to see it like
this:
rule leftop ($leftop, $op) { <$leftop:> [<$op> <$leftop:>]* }
Because I want to give a regex as an op, rather than a string.
What about capturing? What does $leftop contain after a call to
? If it's not a list, how do you make it contain a list? So
many questions... or am I just suffering from A5 forgetfulness?
I know you heavyweights are working out how to specify the return value
from a rule or a capture. Can you do this?
rule leftop ($leftop, $op) {
@rands := [ (<$leftop:>) [ <$op> (<$leftop:>) ] ] {
return \@rands;
}
}
That could work well for rules. Could you do the same for captures?
/ ( @foo := [ ( and) ] { return \@foo } ) {
$1[1] # Second atom
} /
I still thing P6 regexen are gorgeous :)
Luke
Implementing Perl 6 (was Re: Implementing Parse::RecDescentdirectives)
At 2:00 PM -0500 6/15/02, Jonathan Scott Duff wrote: >With all this new syntax, I can't wait until there's a perl6 I can try >it out against rather than just perl6-language. Well, then, time to pitch in! :) Seriously, Parrot's at a state where a not inconsiderable chunk of perl 6 (and perl 5) can be implemented. We have scalars, arrays, hashes, simple I/O, and global variables. While there's some stuff we don't have yet (namely the specialized regex code, stream filters, lexicals, objects, and subroutines) we have more than enough to do much of perl 6. (Even regexes, if you don't mind doing it the slower way to start) We're looking for folks to work on the first cut perl 6 parser over on perl6-internals. All you need is a good knowledge of perl 5 (which is our first cut implementation language) and a willingness to dig through the Apocalypses and Exegeses. (Well, that and not minding the first version likely getting tossed out when we do the final implementation... :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Implementing Perl 6 (was Re: Implementing Parse::RecDescent directives)
Dan Sugalski:
# At 2:00 PM -0500 6/15/02, Jonathan Scott Duff wrote:
# >With all this new syntax, I can't wait until there's a perl6
# I can try
# >it out against rather than just perl6-language.
#
# Well, then, time to pitch in! :)
#
# Seriously, Parrot's at a state where a not inconsiderable chunk of
# perl 6 (and perl 5) can be implemented. We have scalars, arrays,
# hashes, simple I/O, and global variables. While there's some stuff we
# don't have yet (namely the specialized regex code, stream filters,
# lexicals, objects, and subroutines) we have more than enough to do
# much of perl 6. (Even regexes, if you don't mind doing it the slower
# way to start)
#
# We're looking for folks to work on the first cut perl 6 parser over
# on perl6-internals. All you need is a good knowledge of perl 5 (which
# is our first cut implementation language) and a willingness to dig
# through the Apocalypses and Exegeses. (Well, that and not minding the
# first version likely getting tossed out when we do the final
# implementation... :)
If we can use a real parser (Parse::Yapp, Parse::RecDescent), I'd love
to help. If not...well...it'll be Just Too Hard. :^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how warp
drive worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
[COMMIT] New keyed access ops.
'set P3[I5],"foo"' finally works. This probably should have been done a long time ago, but we had some miscommunication problems. True to my previous word, t/pmc/perlarray.t has a new test running Pn[In] &c through its paces. The test only checks the first index, so be prepared for some more fixes once I start testing beyond index zero. -- Jeff <[EMAIL PROTECTED]>
destructors
I'm writing the Parrot_destroy function in embed.c and I noticed that some things like the stacks and the memory allocation system don't have destructors, is there a reason for this?, or should I write them? marcos
Re: destructors
At 7:20 PM -0700 6/15/02, Marco Antonio Valenzuela Escárcega wrote: >I'm writing the Parrot_destroy function in embed.c and I noticed that >some things like the stacks and the memory allocation system don't have >destructors, is there a reason for this?, or should I write them? That part never got written. It's OK to just free up all the arenas and pools during destruction, after the PMC pools have been walked and any live PMCs with destructors have been cleaned up. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
More 6PAN musings: local namespaces
Once nice thing about Java is the class naming convention that lets individual companies (or even individuals, I guess) do custom development that they can safely integrate with the "standard" Java classes and the work of other companies/individuals without fear of namespace clashes. For example, the Acme Corporation can build a huge library of Java code under the com.acme.* namespace: com.acme.widget, com.acme.widget.control, etc. Acme can do this knowing that their stuff will never conflict with the (hypothetical) widget classes in the official Sun JDK, or even widget classes from other companies that make widgets (e.g. com.ibm.widget.*) In the world of Perl 5, things are not nearly as nice. The only convention I recall reading about suggests putting custom code under the Local::* namespace. I've personally never seen anyone use that convention, but even if it was in widespread use, namespace conflicts would still be likely when integrating custom modules from multiple sources unless there are also conventions for further subdivision (e.g. Local::Com::Acme::*) AFAIK, such conventions do not exist (...and I'm going to look really dumb in the rest of this post if they do! :) The result is that "vendor-specific" modules stake out any namespace they want. Some use company name abbreviations (IBM::*), some spell it out (Acme::*), and some just sit right up at the top of the namespace (Widgets::*). More than once, I've seen such custom code (unknowingly) collide with CPAN modules after the fact. Combining multiple collections of custom (i.e. non-CPAN) modules is even more problematic. Now, I don't particularly like the Java convention of com.acme.*, but it does have the advantage of being relatively clear to the reader. And its ties to the domain name system may even make for slightly easier conflict resolution. But it's probably not every Perlish... Nevertheless, I'd like to see some solution to this problem for 6PAN and all Perl 6 modules going forward. Maybe we decided that all 6PAN modules sit "out front" in the namespace. So a 6PAN widget module would get Widget::*. And then maybe we dedicate a subtree of the namespace to custom code and define a convention for naming. If Com::Acme::* or Local::Acme::* is too much, then maybe X::Acme::* or something. Another choice is to deeply nest everything, and then provide a way to reference modules with some part of the (possibly annoying) prefix implied. So maybe the 6PAN widget modules would really be Com::CPAN::Widget, Com::CPAN::Widget::Control, etc., but with some syntactic sugar, it'd look like: mumble Com::CPAN::*; use Widget; use Widget::Control; or whatever. The syntax isn't a big deal, but the namespace isolation is, IMO. I'm sure everyone reading this has written their own modules that were client-specific and not suitable for uploading to CPAN. And I'll bet they've all used slightly different techniques for trying to isolate their custom modules from CPAN modules, and from the rest of the world of custom code. Surely I'm not the only one who's been burned by the failure of this ad hoc system? Like I said in my last "6PAN fretting" post, maybe this has all been thought about before. But I thought I'd throw it out there, just in case :) -John
Re: More 6PAN musings: local namespaces
On Sat, Jun 15, 2002 at 10:35:48PM -0400, John Siracusa wrote: > Once nice thing about Java is the class naming convention that lets > individual companies (or even individuals, I guess) do custom development > that they can safely integrate with the "standard" Java classes and the work > of other companies/individuals without fear of namespace clashes. For > example, the Acme Corporation can build a huge library of Java code under > the com.acme.* namespace: com.acme.widget, com.acme.widget.control, etc. Let's dump out the sack of namespace partitioning problems: What if Acme decides it wants to release part of it's code as Open Source? (Happens a lot). Does it release it as Com::Acme::Text::Thing or Text::Thing? If the name changes, do they have to rewrite all their existing code? Or maybe maintain two names? What if Acme changes it's name? Do they stay as Com::Acme or change all their code? I've experienced something similar to this at a company which was bought and the subsequent s/Old Name/New Name/ in all the copyrights and licenses in all the code. What if Acme Corp. and Acme Widgets Inc. both decide they want to use Com::Acme? What happens if lawyers get involved? What if Acme Corp. decides it wants to enforce it's trademark on Com::Acme? A variation on the last two already happened. Could someone who knows the full story relate what happened when Sun wanted to release it's core Solaris perl modules to CPAN? I know it involved trademarks and guaranteeing a namespace exclusively for Sun. It would be nice to have someone experienced with Java to relate how things have worked out with the com.acme.* scheme. -- This sig file temporarily out of order.
Re: More 6PAN musings: local namespaces
On Sun, 16 Jun 2002, Michael G Schwern wrote: > On Sat, Jun 15, 2002 at 10:35:48PM -0400, John Siracusa wrote: > > Once nice thing about Java is the class naming convention that lets > > individual companies (or even individuals, I guess) do custom development > > that they can safely integrate with the "standard" Java classes and the work > > of other companies/individuals without fear of namespace clashes. For > > example, the Acme Corporation can build a huge library of Java code under > > the com.acme.* namespace: com.acme.widget, com.acme.widget.control, etc. > > Let's dump out the sack of namespace partitioning problems: > > What if Acme decides it wants to release part of it's code as Open Source? > (Happens a lot). Does it release it as Com::Acme::Text::Thing or > Text::Thing? If the name changes, do they have to rewrite all their > existing code? Or maybe maintain two names? > > What if Acme changes it's name? Do they stay as Com::Acme or change all > their code? I've experienced something similar to this at a company which > was bought and the subsequent s/Old Name/New Name/ in all the copyrights and > licenses in all the code. > > What if Acme Corp. and Acme Widgets Inc. both decide they want to use > Com::Acme? What happens if lawyers get involved? > > What if Acme Corp. decides it wants to enforce it's trademark on Com::Acme? You can't get it perfect, realistically. There could always be two parties that want to call their module some name. I mean, you could number modules based on the cardinal (or ordinal... I forget) number of their submission... ha ha hA HA HAAA HAAA! I'm okay with the current setup personally, as far as naming goes. I'd like there maybe to be a more formal classification, say CHS (CPAN Heirarchy Standard). I like it, though, because it's fairly intuitive on my use lines. We haven't had very many collisions thus far. And if they start, that will just force people to be more creative with their naming. And about the local thing, if they don't use (no pun intended) the Local:: heirarchy for local things and their code collides and breaks, that's their problem. Module naming can't be smart for us, we need to help out. Luke
