Re: news gateway through google not working?
That depends if google properly supports moderated newsgroups. Without knowing what they're doing, it's hard to guess what's going on or where your message got eaten. Your message _shouldn't_ show up on google unless it comes through a proper newsfeed. This might mean that google's upstream (stanford) is screwy. -R At Tue, 9 Mar 2004 10:51:06 -0800, Edward S. Peschko wrote: ( ps - on a side note, is the news gateway through google working in posting to the list? I tried posting via google, and although it shows up on google, it didn't show up in the archives... )
Re: news gateway through google not working?
On Mar 9, 2004, at 11:56 PM, Robert Spier wrote: Edward S. Peschko wrote: ( ps - on a side note, is the news gateway through google working in posting to the list? I tried posting via google, and although it shows up on google, it didn't show up in the archives... ) That depends if google properly supports moderated newsgroups. Sounds like they don't ... In any case we don't currently support posting via nntp through anything but nntp.perl.org. - ask -- http://www.askbjoernhansen.com/
Re: Dates and Times
On Sat, 6 Mar 2004, Jared Rhine wrote: It'd be great, if possible, to get a statement here from the DateTime group sanctioning one or another particular Parrot clock interfaces as efficient, complete, and preferred. I haven't poked over to see if they are chatting about this Parrot issue. A few of us have already offered opinions... What we would like for DateTime.pm is an epoch that is _absolutely_ fixed across all platforms. perl does not provide this so we are dependent on the behavior of time(), gmtime(), and Time::Local to make up for this. I have already suggested that Parrot include an op that returns TAI but I would happily settle for gettimeofday(2). What ever is decided upon Parrot should commit to making it consistent across _all_ platforms. -J --
Re: Dates and Times
On Tue, 9 Mar 2004, Edward S. Peschko wrote: On Tue, Mar 09, 2004 at 04:21:24PM -0500, Gordon Henriksen wrote: Not an opcode doesn't mean balkanized. There is a parrot/stdlib directory. fair enough, but then where does the distinction lie? Why put gmtime, et al. in opcodes? As well as addmonth? Returning the current time since epoch x should be an opcode as this is a very common and latency sensitive operation. I believe an awful lot of code only wants to determine the elapsed amount of time by subtracting to subsequent timestamps. Date and time manipulation is complicated and belongs at a much higher level. If you are optimising for simplicity and , it surely makes sense to put these in the standard library. Only if it's a _correct_ implementation. There is no reason why DateTime.pm couldn't be ported to Parrot after object support settles down a bit. If you are optimising for speed, then it makes sense to put them in opcodes. Bloating the core doesn't count as an optimization. But I don't see the 'creeping featuritis' that you see. As well as the memory imprint problems that you see. Is parrot going to link with libc? If so, you get a ton of functionality for (almost) free, just by doing an intelligent wrapper around strftime. As well as providing much of your localization support. And you get a natural boundary on what functionality should be put (in the core) versus what should be put in a module. We all know how consistent the nice vendors are with there libc implementations. :) Do we really want to expose the platform specific strftime() extensions? -J --
Re: Dates and Times
On Tue, 9 Mar 2004, Edward S. Peschko wrote: This sort of creeping featuritis is why date formatting and especially parsing do NOT belong as opcodes. It's too big a problem to solve in the I agree. And the more I think about it, the more I think this concern is misplaced. Putting it in an opcode will make it *harder* to do this type of thing, not easier. In perl5 land, backwards - and forwards - compatibility is a big concern. There will be a large tendency to stabilize any implementation that occurs here. So why do you think time manipulation is about the only thing left out of the x86 ISA? :) -J --
Re: [NEW] library/objecthacks.imc
Hi, On Tuesday 09 March 2004 21:17, Leopold Toetsch wrote: Jens Rieks [EMAIL PROTECTED] wrote: The attached file has some helper functions to make object usage easier. It is used by the new object orientated Data::Dumper implementation as well as my EBNF parser generator. I submit it as a standalone library to reduce code duplication. It might also be useful for other developers too. Please refer to the POD of this library for more information about it. Good. I've seen these functions :) They are fine, except for one: =item (retvals) = __call( obj, methodname, ... ) set S0, S5 set P2, P5 [ snipped a lot more reg moves ] This isn't really looking good. what about: (retvals) = obj.methodname(...) Yes that would be the best solution. I had a cursory look at the IMCC sources, but found no obvious way to implement it. Melvin would that be ok? It *should* be a simple extension of the current function call syntax. We need to emit above two lines additionally and Ccallmethcc instead of Cinvokecc, that's all, AFAIK. Is there a way to get the parent (one should be enough for now) of a ParrotClass? I attached the parent ParrotClass as a property in __new_class, but that does not work anymore because its now possible to use the function with the name of the class to subclass from. Is it possible to get a ParrotClass if the name is known, without having to instantiate an object of that type and using the getclass op on it? If I know how to do that I can add a __multicall function that calls the specified method on all base classes, starting with the root baseclass. It is usefull for constructor calling, to make sure that all base classes are initialized in the proper order. leo jens
[PROPOSAL] Cstat opcode and interface
Proposal Cstat opcode and interface
1) ops
stat (out PMC, in STR, in INT)
stat (out PMC, in PMC, in INT)
Return a new array-like[1] PMC $1 with file stats from file (PIO or
string) $2,
or PerlUndef, if file doesn't exist, $3 are flags:
.PARROT_STAT_NO_FOLLOW_LINK
The array(-like) has keyed access with these keys
.PARROT_STAT_FILE_SIZE
.PARROT_STAT_FILE_SIZE_LO
.PARROT_STAT_FILE_SIZE_HI
.PARROT_STAT_MODE a bitmask with these bits:
.PARROT_STAT_MODE_ISDIR
.PARROT_STAT_MODE_ISFILE
[ more platform-unspecific bits ]
.PARROT_STAT_PERM a bitmask with these bits
.PARROT_STAT_PERM_IS_READABLE
.PARROT_STAT_PERM_IS_WRITABLE
.PARROT_STAT_PERM_IS_EXECUTABLE
.PARROT_STAT_MTIME modified time
.PARROT_STAT_OS_TYPE a constant defining the os-specific
part that follows
.PARROT_STAT_stat
.PARROT_STAT_stat64
...
.PARROT_STAT_OS_SPECIFIC
A (Un)?ManagedStruct PMC with OS-specific data like a
struct stat64
2) Interface
PMC* Parrot_stat_s(Interp*, STRING* file, INTVAL flags);
PMC* Parrot_stat_p(Interp*, PMC*pio, INTVAL flags);
3) Interface to platforms
INTVAL Parrot_stat_os_s(Interp*, Parrot_stat*, STRING* file, INTVAL
flags);
INTVAL Parrot_stat_os_p(Interp*, Parrot_stat*, PMC*pio, INTVAL
flags);
typedef struct _parrot_stat {
size64_t size;
UINTVAL mode;
UINTVAL perm;
FLOATVAL mtime; // in Parrot units
UINTVAL os_stat_type;
union {
struct stat;
struct stat64;
...
} u;
} Parrot_stat;
4) Notes
The information in the first few fields should not be platform
specific. If platforms have more in common then above bits, the
structure should be expanded.
[1] it needs just these vtables implemeted: I0 = P0[i], N0 = P0[i],
i.e. get_{integer,number}_keyed_int
Comments, improvements, and implementations thereafter welcome
leo
Re: A Perl Task - Benchmarking
Sebastian Riedel [EMAIL PROTECTED] wrote: Attached patch should fix that all. Thanks, applied - just updated the sample conf. leo
Re: [NEW] library/objecthacks.imc
Jens Rieks [EMAIL PROTECTED] wrote: Hi, On Tuesday 09 March 2004 21:17, Leopold Toetsch wrote: what about: (retvals) = obj.methodname(...) Yes that would be the best solution. I had a cursory look at the IMCC sources, but found no obvious way to implement it. I'll have a look at it. Is there a way to get the parent (one should be enough for now) of a ParrotClass? No. And what about multiple parents? For SI it's simple. But we could return the immediate parent in seach order. Is it possible to get a ParrotClass if the name is known, without having to instantiate an object of that type and using the getclass op on it? The Cgetclass opcode does return the class PMC. If I know how to do that I can add a __multicall function that calls the specified method on all base classes, starting with the root baseclass. It is usefull for constructor calling, to make sure that all base classes are initialized in the proper order. This should be done inside objects.c. jens leo
Re: [NEW] library/objecthacks.imc
Jens Rieks [EMAIL PROTECTED] wrote: ... It is usefull for constructor calling, to make sure that all base classes are initialized in the proper order. I've checked in a small change to objects. __init get's now called on all parent classes in reverse search order. Then __init on the class is called. jens leo
Re: [NEW] library/objecthacks.imc
Hi, On Wednesday 10 March 2004 12:54, Leopold Toetsch wrote: Jens Rieks [EMAIL PROTECTED] wrote: ... It is usefull for constructor calling, to make sure that all base classes are initialized in the proper order. I've checked in a small change to objects. __init get's now called on all parent classes in reverse search order. Then __init on the class is called. Works great, thank you! I'll write a test for it later today. jens leo jens
Data::Dumper test version
Hi all,
attached is an object orientated version of library/dumper.imc.
(it needs libraray/objecthacks.imc from yesterday)
I made the following changes:
- the third (optional) parameter of _dumper ('indent)' behaves a little bit
different. The string is now repeated for each indention level.
- Unknown PMC are tested for a '__dumper' method, if it has one it is invoked
with the dumper and it's own name (as stored in the cache) as parameters. See
dumper.t test 12 for more information.
The attached archive contains the following files:
- t/pmc/dumper.t.patch
small test adjustments
- library/dumper.imc
a compatibility interface
- library/Data/Dumper.imc
the Data::Dumper class
- library/Data/Dumper/Base.imc
base class for Dumper frontends
- library/Data/Dumper/Default.imc
default Dumper frontend
Comments welcome!
jens
dumper.tgz
Description: application/tgz
[CVS ci] PIR method calls
I have expanded the parser a bit: obj.method(args) ret = obj.method(...) (retvals) = obj.method(...) Cmethod is a label. It's not yet stored in the classes namespace. s. imcc/t/syn/objects.t And plain function calls work now with variables too: .local pmc the_sub the_sub = global _sub the_sub(10, 20) ... .sub _sub leo
Dates and times again
In an attempt to drain the swamp... So far as I can see, we need, in descending order of importance (and speed) (And if there's stuff missing, add them): 1) A timestamp value 2) A way to chop the timestamp to pieces 3) A way to turn the timestamp into a string 4) A way to turn pieces to a timestamp 5) A way to turn the string into a timestamp All of which is confounded by the joys of timezones and platform limitations. As far as I can tell, the only thing we can absolutely count on are: asctime, ctime, difftime, gmtime, localtime, mktime, strftime We can't even count on timegm, unfortunately. Neither can we count on getting fractional time. (Or even really count on getting a GMT time that's actually GMT, as far as that goes, but that's user-misconfiguration and there's a limit to what I'm willing to care about) Nor strptime for time parsing, though a case could be made there that we could do our own. (Cases to be made for that should be accompanied by unencumbered source to do the parsing ;) Can't even count on the full range of output when splitting the time up--if you check the CVS logs you'll see I yanked out a few elements because they're not C89 and there wasn't any way to synthesize them easily that I know of. That means we can't convert to TAI, since that needs leap second info we don't have, so base time can't be TAI. From what I can tell from the interfaces and long painful experience we can't convert to and from anything other than the current system timezone. (Maybe. I'm not 100% sure that's reliable either) Right now, you can get a black-box integer timestamp that's fixed to GMT time, and you can disassemble that timestamp into day/month/year pieces. I adjusted the year to be a real year, but I haven't adjusted the month. We can do that, though. We can easily: *) Give a float timestamp *) Adjust the timestamp to various base dates (I've already made my preferences clear :) My general rule-of-thumb for ops is that they must: *) Be something we want to guarantee behaviour on everywhere *) Require C code *) Have a fixed signature Being primitive isn't necessary as such, but doesn't hurt. Having to be required present at all times isn't necessary either, though we should nail down lexical oplibs if we want to start talking about secondary libraries of this stuff. Anyway, given the restrictions on what we have to work with, the first question is: *) Is what we're providing correct *) What *aren't* we providing that we must to allow full and proper date processing in modules without much pain? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Namespaces in IMCC
At 9:00 PM +0100 3/9/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: While we still need to nail down the final bits of namespace stuff, I'm running into the need for it in IMCC code, so its time to finally deal with it. I don't really care what the syntax looks like, so I'm proposing: .namespace [foo; bar; baz] While I see that's necessary it's not that simple ... Oh, sure it is. :) as a way to set the current namespace for subs to foo::bar::baz. Any sub defined from that point on in the current source file will go into that namespace, unless the namespace is explicitly changed later on. ... because, what does it mean: Any sub [..] will go into that namespace? Well, from what I've seen so far, you're slamming all subs into the base namespace, so that if I have IMCC code that does: .pcc_sub foo .end there's a foo entry in the base namespace. Which is fine. What I want the .namespace (or whatever) thing to do is alter the default namespace that's used. Anway, whe should really define, what are the duties of the PIR assembler towards variable names, name mangling, lexical scopes, namespaces, globals, and all that related stuff. We need it. It's not defined. Fair enough. Generally I don't want the PASM/PIR assemblers to do a whole lot, since I'm not sure it's a good idea. I was going to put this off a bit longer, but I see it's past time to do that. This also gets into the decisions of what metadata goes into the bytecode files and what the bytecode loader is responsible for doing, unfortunately. So we get to revisit bytecode and metadata too. Wheee -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PROPOSAL] Cstat opcode and interface
At 11:39 AM +0100 3/10/04, Leopold Toetsch wrote: Proposal Cstat opcode and interface While we need to do this, what you've got here's far too platform-specific. From long, hard, unpleasant experience I can guarantee that starting with a Unix view of this is going to generate vast amounts of pain in the future. :( Before we dig into the implementation maybe we better take a bit to work out the information we want. From memory, I can think of: *) File size *) Permissions (read, write, execute, delete, enter (for dirs)) and that's for owner, group, everyone, and root *) Times (create, modify, access) *) ACL information (All horribly platform and filesystem specific IIRC) *) Information (file, dir, softlink, hardlink, block dev, char dev, socket, named pipe, semaphore) *) user group of file *) File version (And not just for VMS -- my OS X manpages list this) Some of this information will have to be synthesized on every platform, but with a few exceptions (times, mainly) it's all doable. If there's anything else that needs adding to this list, well, we should do it now. As you've probably noted I'd rather not re-implement and expose 35 years worth of Whoops, that turned out to be a bad idea crud. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Methods and IMCC
Time to nail down some method syntax for IMCC. So, what I'd like (and this is open to discussion) is: Calling a method: object.variable(pararms) object.literal name(params) that is, if the method is referenced with a string register or .local you use the first form and just name the register or local. On the other hand, making a method call with an actual literal string you put the method in quotes. Method declarations: .pcc_sub foo prototyped, method .param pmc foo .param pmc bar .end That is, you add a method on the end of the sub declaration line. If you do so, the local self refers to the object pmc register. (I am OK with unconditionally doing this, in which case we should define some other guaranteed aliases) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PROPOSAL] Cstat opcode and interface
I have no opinion either way on this opcode or the date/time ones, but I
would like to remind folks about miniparrot- if we want it to work again,
there needs to be a smooth way to exclude opcodes or PMCs which are
not expecially portable on its platform (pure c89, no threads, etc).
This means one or more of the following will need to be done:
- all non-c89 code in config/gen/platform
- extra flag in the .ops files to identify ops to be excluded
- extra file to list explicitly which ops should be INcluded in
miniparrot, with all others left out.
- more #ifdef MINIPARROTs.
Personally i'm leaning towards the third option, but I think we should be
clear what the policy is with regard to config/gen/platform and functions
which aren't part of standard C (but which are available on most
platforms).
It's also quite possible that miniparrot is a waste of time. I'm pretty
much of the opinion myself that it's an academic exercise at this point,
but one which keeps us honest, even if we don't use it.
--Josh
--Josh
At 11:39 on 03/10/2004 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote:
Proposal Cstat opcode and interface
1) ops
stat (out PMC, in STR, in INT)
stat (out PMC, in PMC, in INT)
Return a new array-like[1] PMC $1 with file stats from file (PIO or
string) $2,
or PerlUndef, if file doesn't exist, $3 are flags:
.PARROT_STAT_NO_FOLLOW_LINK
The array(-like) has keyed access with these keys
.PARROT_STAT_FILE_SIZE
.PARROT_STAT_FILE_SIZE_LO
.PARROT_STAT_FILE_SIZE_HI
.PARROT_STAT_MODE a bitmask with these bits:
.PARROT_STAT_MODE_ISDIR
.PARROT_STAT_MODE_ISFILE
[ more platform-unspecific bits ]
.PARROT_STAT_PERM a bitmask with these bits
.PARROT_STAT_PERM_IS_READABLE
.PARROT_STAT_PERM_IS_WRITABLE
.PARROT_STAT_PERM_IS_EXECUTABLE
.PARROT_STAT_MTIME modified time
.PARROT_STAT_OS_TYPE a constant defining the os-specific
part that follows
.PARROT_STAT_stat
.PARROT_STAT_stat64
...
.PARROT_STAT_OS_SPECIFIC
A (Un)?ManagedStruct PMC with OS-specific data like a
struct stat64
2) Interface
PMC* Parrot_stat_s(Interp*, STRING* file, INTVAL flags);
PMC* Parrot_stat_p(Interp*, PMC*pio, INTVAL flags);
3) Interface to platforms
INTVAL Parrot_stat_os_s(Interp*, Parrot_stat*, STRING* file, INTVAL
flags);
INTVAL Parrot_stat_os_p(Interp*, Parrot_stat*, PMC*pio, INTVAL
flags);
typedef struct _parrot_stat {
size64_t size;
UINTVAL mode;
UINTVAL perm;
FLOATVAL mtime; // in Parrot units
UINTVAL os_stat_type;
union {
struct stat;
struct stat64;
...
} u;
} Parrot_stat;
4) Notes
The information in the first few fields should not be platform
specific. If platforms have more in common then above bits, the
structure should be expanded.
[1] it needs just these vtables implemeted: I0 = P0[i], N0 = P0[i],
i.e. get_{integer,number}_keyed_int
Comments, improvements, and implementations thereafter welcome
leo
Re: [PROPOSAL] Cstat opcode and interface
Josh Wilmes wrote: It's also quite possible that miniparrot is a waste of time. I'm pretty much of the opinion myself that it's an academic exercise at this point, but one which keeps us honest, even if we don't use it. Miniparrot, or something very much like it, is the final build system. -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia. [Ugh.]
Re: Namespaces in IMCC
Dan Sugalski [EMAIL PROTECTED] wrote: At 9:00 PM +0100 3/9/04, Leopold Toetsch wrote: While I see that's necessary it's not that simple ... Oh, sure it is. :) Well, from what I've seen so far, you're slamming all subs into the base namespace, so that if I have IMCC code that does: .pcc_sub foo .end there's a foo entry in the base namespace. Which is fine. What I want the .namespace (or whatever) thing to do is alter the default namespace that's used. Silly me. Of course. Should be ratber simple to implement. Tomorrow. leo
Re: Methods and IMCC
Dan Sugalski [EMAIL PROTECTED] wrote: Time to nail down some method syntax for IMCC. So, what I'd like (and this is open to discussion) is: Calling a method: object.variable(pararms) Ok. object.literal name(params) A currently already implemented variant is: object.label(params) where label is an unquoted string. I'll do the other two variants tomorrow, if they aren't done - seems simple now:) Method declarations: .pcc_sub foo prototyped, method .param pmc foo .param pmc bar .end That is, you add a method on the end of the sub declaration line. If you do so, the local self refers to the object pmc register. (I am OK with unconditionally doing this, in which case we should define some other guaranteed aliases) alternative syntax: .self me # declare PMC P2 as var me so .pcc_sub foo prototyped, method is .pcc_sub foo prototyped ... .self self which is actually .local pmc self self := P2 leo
Re: PERL_UNICODE and smokes
Op een druilerige winterdag (Wednesday 10 March 2004 12:00), schreef Rafael
Garcia-Suarez:
Abe Timmerman wrote in perl.daily-build :
The recent smoke failures noticed by Merijn are reproducible with
the environment variables
PERL_UNICODE=
LC_ALL=fr_FR.utf8 (or another utf8 locale)
perlrun states clearly that PERL_UNICODE being unset is not equivalent
to PERL_UNICODE=, but to PERL_UNICODE=0. I don't know how
Test::Smoke sets those variables up,
From Test::Smoke::Smoker::make_test()
local( $ENV{PERLIO}, $ENV{LC_ALL}, $ENV{PERL_UNICODE} ) =
( , defined $ENV{LC_ALL} ? $ENV{LC_ALL} : , );
I was merely suggesting something like
local( $ENV{PERLIO}, $ENV{LC_ALL}, $ENV{PERL_UNICODE} ) =
( , defined $ENV{LC_ALL} ? $ENV{LC_ALL} : ,
$ENV{LC_ALL} ? : undef,
);
because if I understand the setup correctly nothing is ever smoked
without PERL_UNICODE=. And the default mode of operation for most
people is with PERL_UNICODE unset.
$ENV{PERL_UNICODE} is explicitly deleted in the cases where the env is not
UTF8 (locale) and so is $ENV{LC_ALL} (unless force_c_locale was set))
$perlio can be one of 'stdio', 'perlio' or 'locale'
if ( $perlio ne 'locale' ) {
$ENV{PERLIO} = $perlio;
$self-{is_win32} and $ENV{PERLIO} .= :crlf;
$ENV{LC_ALL} = 'C' if $self-{force_c_locale};
$ENV{LC_ALL} or delete $ENV{LC_ALL};
delete $ENV{PERL_UNICODE};
Makes sense ?
If I understand you correctly, so much, that it already is this way...
Does the answer to How do I investigate failures? in the Test::Smoke FAQ
help?
Good luck,
Abe
--
Schwern Anything else you'd like? Side order of fries? Clean your stables?
Schwern Get you an apple? Part the Red Sea?
I guess I otherwise would sense some sarcasm in your voice but
unfortunately my sarcasm-o-meter burned out years ago from prolonged
exposure to myself.
-- Jarkko Hietaniemi on p5p @ 2002-02-03
Mutating methods
Perlists, In Perl 5, lc, lcfirst, quotemeta, uc and ucfirst don't mutate. chomp and chop do mutate. I imagine these will all be methods in Perl 6: $foo.lc $foo.quotemeta $foo.chomp I'd like a mutating version of lc, and a non-mutating version of chomp. With some nice syntax, if possible. If there isn't already such a thing in the making, I hereby suggest to re-introduce C.=, to mean more or less the same as in Perl 5, but with Perl 6's version of the C. operator. In other words: C$foo.lc would not mutate and C$foo.=lc would. $foo += 5 === $foo = $foo + 5 $foo.=lc === $foo = $foo.lc Makes sense to me. Especially for Csort it would be nice for something like this: @foo.sort # returns sorted copy versus @foo.=sort # sorts inline I think this syntax reads better than Ruby's exclamation point (foo.method!), because of the analogy with other mutating operators. Please excuse me if this or something like this has already been taken care of - I've searched for messages about it, but haven't found anything. Regards, Juerd
Re: Mutating methods
Juerd writes:
Perlists,
In Perl 5, lc, lcfirst, quotemeta, uc and ucfirst don't mutate.
chomp and chop do mutate.
I imagine these will all be methods in Perl 6:
$foo.lc
$foo.quotemeta
$foo.chomp
I'd like a mutating version of lc, and a non-mutating version of chomp.
With some nice syntax, if possible.
If there isn't already such a thing in the making, I hereby suggest to
re-introduce C.=, to mean more or less the same as in Perl 5, but with
Perl 6's version of the C. operator.
I believe this has been discussed before, and that people generally
liked it. Maybe Larry even did (I seem to recall him saying something
positive about it -- but don't think he did just because I said so :-).
It seems likely that this will go in, though.
I'm in the mood for an exercise, so, here's how you implement it.
Let's say we have the Perl grammar:
grammar Perl
{
# ...
has %.assignment_ops is protected;
rule assignment_expression {
assignment_lhs
$op:= (%.assignment_ops.keys())
$value := %.assignment_ops{$op}{rule}
{
$0 := %.assignment_ops{$op}{transform}($0)
if %.assignment_ops{$op}{transform}
}
}
rule method_call {
term '.' method_name
}
}
Or something. I'm just pulling that out of my ear.
Then we'll derive our own grammar with the C.= operator in, and plunk
it into Perl's parser.
grammar DotEqualsPerl is Perl
{
submethod BUILD() {
.assignment_ops{'.='} = {
rule = /method_name/,
transform = {
Perl::assignment_expression.new(
lhs = .{assignment_lhs},
rhs = Perl::method_call.new(
term = .{assignment_lhs},
method = .{value},
)
)
},
};
}
}
Finally, hooking it into Perl.
use grammar DotEqualsPerl;
Again, this is quite presumptuous about the workings of the Perl::*
classes. The Perl grammar will have to be extremely well documented.
The reason we couldn't just decalre it with Cinfix:.= is because its
right hand side is not a usual expression. That is:
$foo + bar;
Won't parse unless Cbar is a declared sub, whereas:
$foo.bar;
Will always parse.
Luke
Re: Mutating methods
Luke Palmer wrote:
The reason we couldn't just decalre it with Cinfix:.= is because its
right hand side is not a usual expression.
Isn't that what macros are for?
macro infix:.= ($lhs, $rhs) is parsed(/method_name/) {
return Perl::assignment_expression.new(
lhs = $lhs,
rhs = Perl::method_call.new(
term = $lhs,
method = $rhs,
)
);
}
TMTOWTDI, I suppose...
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: Mutating methods
On Wed, Mar 10, 2004 at 05:39:33PM +0100, Juerd wrote: : Perlists, : : In Perl 5, lc, lcfirst, quotemeta, uc and ucfirst don't mutate. : chomp and chop do mutate. : : I imagine these will all be methods in Perl 6: : : $foo.lc : $foo.quotemeta : $foo.chomp : : I'd like a mutating version of lc, and a non-mutating version of chomp. : With some nice syntax, if possible. : : If there isn't already such a thing in the making, I hereby suggest to : re-introduce C.=, to mean more or less the same as in Perl 5, but with : Perl 6's version of the C. operator. Except that C. isn't really a binary operator... On the other hand, draft -1 of A12 has a conjectural my Dog $dog .= new() in it, and that's even further out there, since the .new on the right would in fact be called on a $dog that is undefined! : In other words: C$foo.lc would not mutate and C$foo.=lc would. : : $foo += 5 === $foo = $foo + 5 : $foo.=lc === $foo = $foo.lc : : Makes sense to me. Yes, but the fact that you had to change the spacing bothers me. : Especially for Csort it would be nice for something like this: : : @foo.sort # returns sorted copy : : versus : : @foo.=sort # sorts inline : : I think this syntax reads better than Ruby's exclamation point : (foo.method!), because of the analogy with other mutating operators. Well, I'd like to reserve postfix:! for factorial in any event. :-) The basic problem with .= shows up when you do put the spaces in: @foo .= sort() That makes it look as though sort is a subroutine, and it's not. That's a direct result of the fact that C. is not really a binary operator. Rather, it's a kind of operator sigil that introduces a unary postfix operator. Method calls are really unary postfix operators that happen to be able to take extra arguments. And because the op= syntax is really built for binary operators, it doesn't totally work for unary operators. Take another unary postfix operator, for instance, an array subscript: @array[$x] you can't just up and say @array[=$x] to mean @array = @array[$x] to turn it into a mutating operator, because the [$x] wants to function as a unit, and the = breaks that up. Similarly, .sort wants to function as a unit, but the = breaks that up, visually and semantically. However, having said all that, it turns out that A12 will also introduce other dot variants: $obj.?method# call method if exists, or return undef (0 or 1) $obj.*method# call all base class methods of that name (0 or more) $obj.+method# call all base class methods of that name (1 or more) So a .=method syntax is not so farfetched. It analogies to +=, but it's really still just a prefix to a unary postfix operator, like the other dot variants. The interesting question with all of these dots is where spaces are allowed or disallowed. One could make a case that people will want to write my Car $obj .= new() rather than being forced to write my Car $obj .=new() It could even be argued that, in the case of this particular operator, the = is functioning as part of the name, as the ! does in Ruby. So if (hypothetically) we allow a space after the ordinary dot @array . sort then we could also allow things like: @array . =sort $obj . *initialize $obj . ?maybe But I dislike $variable . meth() for the same reason I dislike $variable .= meth() because it makes meth look like a subroutine call when it isn't. Regardless of how fancy they get, method calls are still postfix operators. So I'm inclined to say that the space is only optional before the dot, and you have to say @array .sort @array .=sort $obj .*initialize $obj .?maybe But that still makes my Cat $tom .=new() pretty ugly. Unfortunately we can't just use topicalization to say my Cat $tom = .new() because most people won't expect simple assignment to break their current topic. So another option is to replace = with something that Idoes set the topic for the right side. If we used .= for that, then you'd have to write @array .= .sort my Cat $tom .= .new() Doubtless the first would get shortened to @array.=.sort That does admit to constructs like $foo .= .*bar which would assign $foo a list of all the return values of $foo.*bar, or $foo .= .?maybe which would presumably replace $foo with an undefined value if it couldn't find $foo.maybe. Those don't seem terribly useful as mutators though. They'd be much clearer written out long. Another approach would be to have some kind of microtopic that represented the left side of an ordinary assignment. Suppose for the sake of argument that the microtopic is ^. Then you could write @array = ^.sort; and a constructor would be my Kanga $roo = ^.new() But that introduces a new concept that doesn't really generalize well. So forget that. Yet another approach is to *replace* dot
Re: Mutating methods
On Wed, Mar 10, 2004 at 11:19:52AM -0800, Brent Dax Royal-Gordon wrote:
: Luke Palmer wrote:
: The reason we couldn't just decalre it with Cinfix:.= is because its
: right hand side is not a usual expression.
:
: Isn't that what macros are for?
:
: macro infix:.= ($lhs, $rhs) is parsed(/method_name/) {
Methods are really postfix operators, so that would probably be
something more like:
macro postfix:.= ($lhs, $parsetree)
is parsed(/ws? ?method_name ?method_args/) {
That's presuming we allow whitespace after the . and .= ops.
(Also, these days you have to say ?foo to collect the results into $0.)
Larry
Re: Mutating methods
Larry Wall writes:
On Wed, Mar 10, 2004 at 11:19:52AM -0800, Brent Dax Royal-Gordon wrote:
: Luke Palmer wrote:
: The reason we couldn't just decalre it with Cinfix:.= is because its
: right hand side is not a usual expression.
:
: Isn't that what macros are for?
:
: macro infix:.= ($lhs, $rhs) is parsed(/method_name/) {
Methods are really postfix operators, so that would probably be
something more like:
macro postfix:.= ($lhs, $parsetree)
is parsed(/ws? ?method_name ?method_args/) {
That's presuming we allow whitespace after the . and .= ops.
(Also, these days you have to say ?foo to collect the results into $0.)
Hooray! That was something I had been worried about.
But C? doesn't seem to fit visually. What's questionable about
that?
I can think of a couple that I like better:
^foo
*foo
^foo is my favorite at the moment (even though *foo is more
visually pleasing), because it looks like it's transferring the
information ^up^ in the parse tree.
Luke
Re: Mutating methods
Luke Palmer wrote: Hooray! That was something I had been worried about. But C? doesn't seem to fit visually. What's questionable about that? Nothing questionable, but everything hypothetical: ?foo captures to the $?foo hypothetical variable Damian
Re: Mutating methods
On Wed, Mar 10, 2004 at 12:42:00PM -0700, Luke Palmer wrote:
: (Also, these days you have to say ?foo to collect the results into $0.)
:
: Hooray! That was something I had been worried about.
:
: But C? doesn't seem to fit visually. What's questionable about
: that?
It's questionable insofar as it's hypothetical. It maps to $?foo,
which is the name of the (current value of the) capture within any
interior closure:
/?foo { say Guessing $?foo for the moment... bar } /
: I can think of a couple that I like better:
:
: ^foo
: *foo
:
: ^foo is my favorite at the moment (even though *foo is more
: visually pleasing), because it looks like it's transferring the
: information ^up^ in the parse tree.
But $^foo and $*foo mean very different things from hypotheticals.
And in a real sense $?foo is passing guessed information *down*
the match. The guesses only turn out right if you get all the way
to the bottom successfully. (That's from the point of view that
you recurse deeper to check anything to the right in a regex, even
when syntactically it's shallower.)
Larry
Re: Mutating methods
Larry Wall writes:
On Wed, Mar 10, 2004 at 12:42:00PM -0700, Luke Palmer wrote:
: I can think of a couple that I like better:
:
: ^foo
: *foo
:
: ^foo is my favorite at the moment (even though *foo is more
: visually pleasing), because it looks like it's transferring the
: information ^up^ in the parse tree.
But $^foo and $*foo mean very different things from hypotheticals.
And in a real sense $?foo is passing guessed information *down*
the match. The guesses only turn out right if you get all the way
to the bottom successfully. (That's from the point of view that
you recurse deeper to check anything to the right in a regex, even
when syntactically it's shallower.)
Hmm... that makes sense.
It doesn't feel right, though. After all, we don't say:
($minutes, $seconds) = m/ (? \d\d ) : (? \d\d ) /;
Even though they only stay matched if they get to the end without
backtracking. Capturing (this is really just a clever notation for
captures) is usually about communicating information Ioutside of the
match: to the parent rule, to the the calling scope.
As you showed in your reply about C.=:
macro postfix:.= ($lhs, $parsetree)
is parsed(/ws? ?method_name ?method_args/)
{ ... }
There's nothing about C? that makes me think that these are being
stored.
I understand the association with C$?foo. But most of the time, when
I'm writing a grammar, I'm catching these rules in order to stick them
in the parse tree, not to do tests on them later on in the rule. The
very essence of rules is hypotheticality, where nothing is permanent
until it gets to the end. I don't think we need a special marker that
says these do that, too.
Luke
Re: Mutating methods
Luke Palmer wrote: I understand the association with C$?foo. But most of the time, when I'm writing a grammar, I'm catching these rules in order to stick them in the parse tree, not to do tests on them later on in the rule. The very essence of rules is hypotheticality, where nothing is permanent until it gets to the end. I don't think we need a special marker that says these do that, too. We need the marker to distinguish between hypothetical captures to internal variables: / $?foo:=(abc) $?bar:=(def) / and non-hypothetical captures to external variable: / $foo:=(abc) $bar:=(def) / And since subrules that capture always capture to hypotheticals, we need the same marker there. Damian
Re: Mutating methods
Damian Conway wrote: / $foo:=(abc) $bar:=(def) / Am I misreading, or are you suggesting that $foo may contain 'abc' after running this example, even if the match wasn't successful? -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: [PROPOSAL] Cstat opcode and interface
At 10:11 AM -0800 3/10/04, Brent \Dax\ Royal-Gordon wrote: Josh Wilmes wrote: It's also quite possible that miniparrot is a waste of time. I'm pretty much of the opinion myself that it's an academic exercise at this point, but one which keeps us honest, even if we don't use it. Miniparrot, or something very much like it, is the final build system. Yep. We need to make sure it always works. Which, unfortunately, will end up making things a hassle, since there's no platform-independent way to spawn a sub-process, dammit. :( -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PROPOSAL] Cstat opcode and interface
Dan Sugalski wrote: Which, unfortunately, will end up making things a hassle, since there's no platform-independent way to spawn a sub-process, dammit. :( Unixen seem to support system(). So does Windows. I suspect that most OSes we want to run on have something pretty equivalent, even if it doesn't have the exact same name. (Except for Palms, but Palms are always cross-compiled to. Although I *did* see one C compiler that ran on the Palm...) I think that, in this particular area, it's okay to introduce a bit of platform dependence into Miniparrot via #ifdefs. It's a critically important function for Miniparrot to do its job, and if we're careful about what programs we call and what sort of I/O redirections we try to use, the portability concerns aren't too daunting. Remember, the real thing won't be using 'perl -e', so quoting constructs may not even come into play. The plan was always *three*-step: platform specific shell script - miniparrot - full parrot The shell scripts (or batch files, or...) in the first steps can pass a couple extra -Ds to Miniparrot if they're really necessary. -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: [PROPOSAL] Cstat opcode and interface
At 12:53 PM -0500 3/10/04, Josh Wilmes wrote: It's also quite possible that miniparrot is a waste of time. I'm pretty much of the opinion myself that it's an academic exercise at this point, but one which keeps us honest, even if we don't use it. Nope, not a waste of time at all. It is part of the big plan, and as such is really, really important. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PROPOSAL] Cstat opcode and interface
At 11:12 AM -0800 3/10/04, Brent \Dax\ Royal-Gordon wrote: Dan Sugalski wrote: Which, unfortunately, will end up making things a hassle, since there's no platform-independent way to spawn a sub-process, dammit. :( Unixen seem to support system(). D'oh! It's C89 standard. I'm getting stuck in the 80s with the multitude of exec variants. Yeah, with that issue taken care of it's a lot more doable. Nevermind... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[BUG] load_bytecode can print hello world
Hi, this time a funny bug :-) 1. create a file main.imc with the following content: .sub _main print A\n load_bytecode hello.imc print B\n end .end 2. create a file hello.imc with the following content: .emit .pcc_sub @LOAD _onload: print foo\n end .eom .sub _hello print blah blah string\n load_bytecode hello, world!\n end .end 3. run main.imc jens
Re: news gateway through google not working?
That depends if google properly supports moderated newsgroups. Sounds like they don't ... In any case we don't currently support posting via nntp through anything but nntp.perl.org. Actually, I think we need to get the uunet.uu.net folks to setup some entries for us. But I can't find a contact address. -R
Re: [DOCS] Documentation tools
[EMAIL PROTECTED] (Dan Sugalski) writes: [...] It's an ongoing fight between the go get the libs and install them folks and the self-contained distribution folks. I'm in the latter category. :) As Larry said, self-contained is good for users. For developers (and CVS) go get the libs is appropriate. A script can assemble the user distribution(s) with pre-defined versions of the libs to include. - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: [PROPOSAL] Cstat opcode and interface
On Wed, Mar 10, 2004 at 10:58:14AM -0500, Dan Sugalski wrote: : *) Times (create, modify, access) Just a reminder that ctime on Unix is not create time, but time of last inode change. I wish there were a create time on Unix, but there ain't. Larry
Re: Dates and times again
On Wed, Mar 10, 2004 at 09:59:32AM -0500, Dan Sugalski wrote: : That means we can't convert to TAI, since that needs leap second info : we don't have, so base time can't be TAI. That part is only half true. Or maybe less than half, if UTC decides to cut loose from astronomical time and ends up tracking TAI exactly from now on. But we *do* know the mappings in the past. (Well, for the recent past, anyway. :-) : Right now, you can get a black-box integer timestamp that's fixed to : GMT time, and you can disassemble that timestamp into day/month/year : pieces. I adjusted the year to be a real year, but I haven't adjusted : the month. We can do that, though. We can easily: : : *) Give a float timestamp That would seem like good future proofing. Someday every computer will have decentish subsecond timing. I hope to see it in my lifetime... : *) Adjust the timestamp to various base dates (I've already made my :preferences clear :) 0 on 1/1/2000 works out very well if it turns out we don't do UTC leaps seconds any more. Then TAI and UTC only go nonlinear before 2000, and so far that's in the past, which is generally easier to predict afterwards, given enough historical evidence. And if they do add leaps to UTC in the future, then at least TAI and GMT always march in lockstep, and we'll be no worse off than we are now. :-) It will be very good if the fate of leap seconds is decided well before POSIX has to consider how to store time after that date in 2038. --http://www.ucolick.org/~sla/leapsecs/onlinebib.html My guess is that eventually they'll decide to put a moratorium on leap seconds, with the recommendation that the problem be revisited just before 2100, on the assumption that we'll add all of a century's leap seconds at once at the end of each century. That would let civil time drift by at most a minute or two before being hauled back to astronomical time. More to the point, it would put the problem off till another day (not to mention another generation). So that's my prediction. But then, I'm terrible at time estimation... : *) Is what we're providing correct I'd say what's missing are the error bars. I don't mind if the timestamp comes back integral on machines that can't support subsecond timing, but I darn well better *know* that I can't sleep(.25), or strange things are gonna happen. : *) What *aren't* we providing that we must to allow full and :proper date processing in modules without much pain? Snap-to-grid semantics for when the clock inevitably gets off by a second or two from somebody's idea of the correct time. (But that should be solved in your levels two through five, not in the timestamp.) The basic idea is I can add 86400 seconds to yesterday and I get the same time today, even if there was a leap second. One would have to request such a snap explicitly, I expect, because you'd have to communicate to it that you don't actually care about sub-minute times, or whatever your grid specifies. But that's how graphics programmers solve the mouse jitter problem, and I think we can learn from them. Larry
Objects, init, and vtable limits
We've gone back and forth on this before, and it's time to go for yet another round. Right now, we can create new PMCs by calling the class init method. It takes no parameters which somewhat limits the utility of the thing as a true initializer. There's an init vtable method that takes a property PMC, but that's kind of awkward. Now, we've three real options here. We can: 1) Treat the init method as an allocator, and leave initialization to an explicit sub/method call 2) Have one single vtable method that has a different set of calling conventions from every other method and sub available from bytecode 3) Make new use the registers and obey the calling conventions Now, I don't really like #3, as it's damned inconvenient. #2 has this nasty inconsistency to it that I'm not thrilled with either, though I can definitely live with it. #1 leaves us with the possibility of split allocation and initialization and I've been warned about that as a Bad Idea. (OTOH we're at a low-enough level that it's arguably OK) I'm up for discussion on this, as well as other options, so... have at it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Mutating methods
Brent Dax Royal-Gordon wrote: / $foo:=(abc) $bar:=(def) / Am I misreading, or are you suggesting that $foo may contain 'abc' after running this example, even if the match wasn't successful? No. I re-checked with Larry this morning and he confirmed that all bindings in rules only stick if the rule as a whole succeeds. What I was trying (obviously rather ineptly ;-) to point out is that we have to be able to differentiate between the the match object's own internal hypothetical variables ($?foo, $?bar, @?baz) and any external-but-temporarily-hypothesized variables ($foo, $bar, @baz). The syntax we've chosen to do that requires the use of ? as a secondary sigil on internal variables. So, since named subrules that capture always capture to internal variables, it's natural and consistent to use ? to indicate capturing subrules as well. Damian
RE: Mutating methods
I was thinking along the lines of... String $foo = hello; $foo.scramble! print $foo\n; $foo = hello print $foo.scramble ~ \n; print $foo; OUTPUT (or close): elhlo hloel hello Also, along these same things.. is there a way to apply a method to all variables/objects of a certain type (e.g. String, Num, etc)? Taking the above example.. being able to write a method called Scramble that can be called as a method from any String type.
Re: Mutating methods
On Wed, Mar 10, 2004 at 10:46:05PM -0500, matt wrote:
: I was thinking along the lines of...
:
: String $foo = hello;
: $foo.scramble!
That would be $foo.=scramble in the current scheme of things.
: print $foo\n;
: $foo = hello
: print $foo.scramble ~ \n;
: print $foo;
:
: OUTPUT (or close):
: elhlo
: hloel
: hello
:
: Also, along these same things.. is there a way to apply a method to all
: variables/objects of a certain type (e.g. String, Num, etc)? Taking the
: above example.. being able to write a method called Scramble that can be
: called as a method from any String type.
Two ways, actually. You can 'reopen the String class and add the method:
class String is extended {
method scramble () returns String {...}
}
or if you consider that underhanded, you can define a multi-sub:
multi sub *scramble (String $s) returns String {...}
If you call that as a method, and there is no ordinary scramble method,
it will fail soft to looking for a scramble multimethod, and end up
calling your definition. Or you can just call it directly as a function:
scramble(hello)
Larry
RE: Mutating methods
-Original Message-
From: Damian Conway [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 10 March, 2004 09:48 PM
To: [EMAIL PROTECTED]
Subject: Re: Mutating methods
Brent Dax Royal-Gordon wrote:
/ $foo:=(abc) $bar:=(def) /
Am I misreading, or are you suggesting that $foo may contain
'abc' after
running this example, even if the match wasn't successful?
No. I re-checked with Larry this morning and he confirmed that
all bindings in
rules only stick if the rule as a whole succeeds.
What I was trying (obviously rather ineptly ;-) to point out is
that we have
to be able to differentiate between the the match object's own internal
hypothetical variables ($?foo, $?bar, @?baz) and any
external-but-temporarily-hypothesized variables ($foo, $bar, @baz).
The syntax we've chosen to do that requires the use of ? as a secondary
sigil on internal variables. So, since named subrules that capture always
capture to internal variables, it's natural and consistent to use ? to
indicate capturing subrules as well.
Isn't this backwards?
That is, from the above I get the impression that $?foo is TRANSIENT, while
capturing to $foo will (eventually) be PERMANENT.
So ?foo is just a shorthand way of saying
$?foo := foo
right?
Is hypo-space a flat entity, or do hypothetical scopes nest? If so, do we
have to use repeated ?'s, or will just one suffice?
That is:
rule bar {...}
rule baz {...}
rule foo {...bar...baz...}
if / ?foo ... ?baz ... { $?foo.?baz ... $?baz } .../
OR
if / ?foo ... ?baz ... { $?foo.baz ... $?baz } .../
OR
if / ?foo ... ?baz ... { $?baz ... $?otherbaz } .../
=Austin
Re: Mutating methods
On Thu, Mar 11, 2004 at 01:09:59AM -0500, Austin Hastings wrote:
:
:
: -Original Message-
: From: Damian Conway [mailto:[EMAIL PROTECTED]
: Sent: Wednesday, 10 March, 2004 09:48 PM
: To: [EMAIL PROTECTED]
: Subject: Re: Mutating methods
:
:
: Brent Dax Royal-Gordon wrote:
:
: / $foo:=(abc) $bar:=(def) /
:
: Am I misreading, or are you suggesting that $foo may contain
: 'abc' after
: running this example, even if the match wasn't successful?
:
: No. I re-checked with Larry this morning and he confirmed that
: all bindings in
: rules only stick if the rule as a whole succeeds.
:
: What I was trying (obviously rather ineptly ;-) to point out is
: that we have
: to be able to differentiate between the the match object's own internal
: hypothetical variables ($?foo, $?bar, @?baz) and any
: external-but-temporarily-hypothesized variables ($foo, $bar, @baz).
:
: The syntax we've chosen to do that requires the use of ? as a secondary
: sigil on internal variables. So, since named subrules that capture always
: capture to internal variables, it's natural and consistent to use ? to
: indicate capturing subrules as well.
:
: Isn't this backwards?
:
: That is, from the above I get the impression that $?foo is TRANSIENT, while
: capturing to $foo will (eventually) be PERMANENT.
$?foo is exactly as transient as the $0 in which it resides. So it
really depends on how long $0 lives outside the regex. In the case
of a returned parse tree it could live a very long time.
: So ?foo is just a shorthand way of saying
:
:$?foo := foo
:
: right?
Yes. The ? is actually serving as a scope marker telling Perl not
to scan outside of the current regex for a variable of that name.
If you consider each rule to be its own package, it's kind of an our
declaration within the rule.
: Is hypo-space a flat entity, or do hypothetical scopes nest?
Um, the namespace inside a particular rule is flat, just as the
namespace inside a package is flat. That doesn't mean that your code
won't visit those variables in whatever order it jolly well pleases.
Dynamically speaking, every assertion in a regex is recursively matched inside
the results of previous successful assertions, regardless of the
lexical structure of the rule. You're often in situations where dynamically
you're going down recursively, while in terms of where you are in the
match, you're going out of brackets or parens. It has to be that way,
or you could never backtrack into a set of brackets or parents.
But once a subrule is matched, all its ? names are bundled up into
a hash in the single $0-ish object that becomes aliased (at least
temporarily) to the $?foo in the outer rule. The keys of that hash are
flat for all the names in the particular rule, though of course some
of the values may be nested $0 results from subrules. So effectively
you end up with a hash of hash of hash of hash representing the
entire syntax tree. But any given rule can't produce more than one
level of hash (without doing something freaky like rewriting your
hash entries inside a closure).
: If so, do we
: have to use repeated ?'s, or will just one suffice?
:
: That is:
:
:rule bar {...}
:rule baz {...}
:rule foo {...bar...baz...}
:
:if / ?foo ... ?baz ... { $?foo.?baz ... $?baz } .../
: OR
:if / ?foo ... ?baz ... { $?foo.baz ... $?baz } .../
: OR
:if / ?foo ... ?baz ... { $?baz ... $?otherbaz } .../
Well, you don't need ? to go down the syntax tree, since each $0
can behave as a hash. You don't subscript hashes using . either.
You subscript hashes with {...} historically, or these days, «...»,
when you want constant subscripts. So what you're looking for is
something like:
if / ?foo ... ?baz ... { $?foo{'baz'} ... $?baz } .../
or
if / ?foo ... ?baz ... { $?foo«baz» ... $?baz } .../
or even:
if / ?foo ... ?baz ... { $0«foo»«baz» ... $0«baz» } .../
Oh, and since the current $0 is actually the topic of any closure,
you can also probably say
if / ?foo ... ?baz ... { .«foo»«baz» ... .«baz» } .../
as an analog to
if / ?foo ... ?baz ... { .{'foo'}{'baz'} ... .{'baz'} } .../
That's presuming we keep the rule that scalars don't have to include
the sigils. For an array you'd still have to say:
if / @?things:=[ (ident) ,? ]+ { ... [EMAIL PROTECTED] ... } /
or
if / @?things:=[ (ident) ,? ]+ { ... [EMAIL PROTECTED] ... } /
But then it's usually easier just to say
if / @?things:=[ (ident) ,? ]+ { ... @?things ... } /
which means exactly the same thing.
Larry
