Re: Implementation of :w in regexes and other regex questions
On 2/14/06, Luke Palmer [EMAIL PROTECTED] wrote:
On 2/14/06, David Romano [EMAIL PROTECTED] wrote:
I don't want to just skip B tags wholly, because they do serve a purpose,
but only in a particular context. (Can ?ws be changed back to a default
if
changed to include html tags?)
Brackets serve as a kind of scoping for modifiers. We're also
considering that :ws take an argument telling it what to consider to
be whitespeace. So you could do:
rule Month :w {
[ :w(my_ws) J a n ] # not sure about the
# out here we still have the default :w
}
Ahh, okay. So am I to understand that my_ws would just return a set of
individual characters or character sequences that would be considered
whitespace? Or would my_ws do something else?
Would something like below be easier to decode for a human reader?
text:without(date) {
^ [.*] $
}
Well, if you could define exactly what it means, then perhaps. Does
that mean that date appears nowhere within the matched text, or that
it just doesn't appear at the beginning. In either case, you can make
these rules grammar friendly by including your test at the end:
rule text_no_date {
(.*)
{ $1 !~ /date/ }
}
This is what I was thinking: nowhere within the matched text...hadn't
thought about the closure at the end.
If that adverb were available, then I could have a rule that doesn't include
two other rules:
line:without(datename) {
^^ [.*] $$
}
The rule above would match a line with a date or name, but not a line
with
both.
Huh. That kind of test really wants a closure. You can't use the
regex because that requires that they match at the same place. You
can't use the logical , because date isn't an expression. Of
course, that is unless you include your own parsing rule, but that
isn't recommended.
I see. I guess I initally thought that it would be nice to have
important information like exclusions at the beginning, rather than at
the end, of a rule. Thanks again for the explanations and pointers.
David
Re: Implementation of :w in regexes and other regex questions
On Tue, Feb 14, 2006 at 11:35:18AM -0800, David Romano wrote:
On 2/14/06, Luke Palmer [EMAIL PROTECTED] wrote:
On 2/14/06, David Romano [EMAIL PROTECTED] wrote:
I don't want to just skip B tags wholly, because they do
serve a purpose, but only in a particular context. (Can ?ws
be changed back to a default if
changed to include html tags?)
Brackets serve as a kind of scoping for modifiers. We're also
considering that :ws take an argument telling it what to consider to
be whitespeace. So you could do:
rule Month :w {
[ :w(my_ws) J a n ] # not sure about the
# out here we still have the default :w
}
Ahh, okay. So am I to understand that my_ws would just return a set of
individual characters or character sequences that would be considered
whitespace? Or would my_ws do something else?
I would think that my_ws would be a rule of some sort:
rule my_ws { [ \s+ | \ /? b \ ]* }
Also, it wasn't noted in the previous post, but one can
explicitly call the default ws rule by referring to it explicitly,
as in Rule::ws. (Currently PGE has it as PGE::Rule::ws.)
So, presumably one could do
rule Month :w(my_ws) { J a n # my_ws rule here
[:w(Rule::ws) . . . ] # default ws rule here
[:w(0) . . . ] # no :w here
PGE doesn't yet implement rule arguments to the :w modifier, but
I bet we can add it without too much trouble. :-)
Pm
This week's summary. Part 1
The Perl 6 summary for the week ending 2006-02-12
Welcome to part one of this week's summary. Owning to chronic problems
with deadlines I've only got time to summarize perl6-compiler and
perl6-internals tonight; I'll do perl6-language when I get back from
$paying_job on Thursday night.
You shall just have to contain your excitement 'til then.
This week in perl6-compiler
Tokenizer hints, supporting delimited identifiers or symbols
Darren Duncan said that he'd like for there to be a simple and terse way
for Perl 6 identifiers or symbols to be able to composed of any
characters whatsoever (even whitespace). After all, it's allowed in lots
of other languages (including, although Darren didn't mention it, Perl 5
-- consider ${var with spaces} = 'foo' if you don't believe me.
Lexical vars are a wee bit trickier).
I turns out that, as Larry said $::You can already do that!;, which
is nice. It turns out there's quite a few ways of doing it and Larry
discussed them all.
http://xrl.us/j2bf
Meanwhile, in perl6-internals
Parameter count checks
One of the tricky things about having PIR level parameter count checks
is coming up with a good syntax for it; in particular, Chip wanted an
easy way of expressing common things like void calls. It turns out out
that Common Lisp is one of the trickier languages to deal with here
since it allows for multiple values returned from a function, but
ignores every return apart from the first unless you specifically ask
for them. Which can be nice, but is weird.
I'm not sure we have a syntax for it yet, I'm sure one will be
forthcoming eventually.
http://xrl.us/j2bg
Add methods in dynpmc
François Perrad had some trouble adding methods to Lua PMCs and asked
for help. Leo provided it and all was gorgeousness again.
http://xrl.us/j2bh
{null,parrot,installable}_config.o
Florian Ragwitz is the Debian maintainer of the pugs and parrot packages
and he has problems getting the latest pugs to link with Parrot, mostly
because of the way parrot stores information about where things are
installed. He made a few suggestions for resolving the issue. I'm not
sure Leo's answer was much use to him.
http://xrl.us/j2bi
Heureka - from the -Ofun department
Leo announced that Parrot is now running the Ackermann benchmark faster
than C. It turns out that tail recursion elimination is a really good
thing to have. It also turns out that we only get the really blistering
speed on x86 and ppc architectures, because those are the architectures
with a working JIT core. Things aren't quite so rosy on SPARC, for
instance.
Still. Wow!
http://xrl.us/j2bj
:non_volatile is now :unique_reg
Jonathan Worthington checked his :non_volatile patch back in, but with
the new :unique_reg name. Which is nice.
http://xrl.us/j2bk
Sub introspection: filename and line
Jerry Gay had some questions to ask about walking the Parrot call chain
and getting at file and line info. It turns out that the Sub PMC doesn't
have the methods he needs. Johnathan Worthington corrected what he'd
said on IRC about how to walk the call chain, pointing out that, instead
of walking subs, you need to walk contexts, but that contexts aren't
actually PMCs because we don't have weak references yet.
Apparently, we will have weak references eventually, at which point
we'll be able to have context PMCs, which can be used for introspecting
on the call chain.
Me? I don't quite understand what's the difference between these
'contexts' of which Jonathan speaks and return continuations. But I'm
odd like that.
http://xrl.us/j2bm
Q. Namespaces and classes
Leo wasn't entirely sure of what semantics are needed by namespace PMCs.
He talked around the issues and asked if he was going along sane lines.
I can't tell if Jonathan thought Leo was sane or not, but Leo seemed to
find the response useful.
http://xrl.us/j2bn
Quis custodiet ipsos custodes?
Misspelling Juvenal slightly, Jerry Gay observed that there are no tests
for Parrot::Test and made a plea for this to be remedied. You're on your
own with the Latin.
http://xrl.us/j2bo
PIC/JIT update
Leo announced that the PPC JIT core can now compile subs on the fly,
just like the x86 core. But only for integer code apparently.
http://xrl.us/j2bp
Integer divide overflow
Leo observed an overflow issue with integer division and asked for
comments. Jonathan Worthington suggested going to the pub. It won't fix
the problem, but we'll feel better about it. We definitely seem to be
in Don't do that then. territory.
http://xrl.us/j2bq
Find a multi-method/multi-sub by name and signature
Jonathan Worthington's work on a .NET translator 'ambles on'. He's
working on mapping .NET's static
Re: Instance attributes collision
On 2/12/06, Yiyi Hu [EMAIL PROTECTED] wrote:
For perl 6,
Array and Scalar are in different namespace.
So,
class A { has $.a; has @.a };
what will A.new.a return by default?
An Error? or Scalar has a higher priority?
It seems to me that the best way to approach this issue is to seperate
the accessor generation from the attribute declaration.
To start with, in Perl 5, it is entirely possible to do this without ambiguity:
package Foo;
our $bar;
our @bar;
This is because '$bar' and '@bar' are different names. Perl 6 should
follow this, and store the meta-objects which represent these
attributes using different names as well, so given:
class A {
has $.a;
has @.a
};
You would find two attribute meta-objects, one keyed to '$.a' and the
other to '@.a', and there is no ambiguity.
Now for the accessor generation portion of this question.
Accessor generation should probably take place towards the end of
class construction. You need to think of class construction as a
multi-step process, first the name is encountered:
class A;
At this point a metaclass should be created and named A. Next the body
of the class should be evaluated within the context of the metaclass.
As each attribute declaration is encountered, it should be converted
to metaclass calls to further construct the class. So things like
this:
has $.a;
Will translate to something like this:
$::CLASS.add_attribute(Perl6::Meta::Attribute.new(:name$.a));
Now, when the classes body has been completely evaluated, a method
should be called on the metaclass (found in the $::CLASS
pseudo-lexical variable) to tell the metaclass that that class
construction has been finished. This method should finish up the class
construction and at this point the attribute accessors should now be
generated.
Now, here is my proposal for how accessor generation should be handled.
I think that the metaclass (stored in the pseudo-lexical $::CLASS)
should create a number of anonymous roles on the fly:
role {
multi method a (::CLASS $self) { ... }
multi method a (::CLASS $self, Scalar $value) { ... }
}
role {
multi method a (::CLASS $self) { ... }
multi method a (::CLASS $self, Array @value) { ... }
}
These roles would then be added to the metaclass using the normal
rules of role composition. (NOTE: I assume that ::CLASS is unbound
until the role is composed into a class, I think A12 might have stated
this detail)
Now obviously we have a conflict in our multi-methods. S12 only states
that multi methods will be compared by their long names (name +
signature) to resolve ambiguity, it does not state what happens when
those long names conflict. I propose that they work just as normal
method conflicts do, which is that both methods are excluded and the
consuming class is then required to implement that method.
So now, if we follow the rules of role composition, when these two
anonymous roles are added to the metaclass, there will be a conflict
and class composition will fail.
So the short answer is that this:
class A {
has $.a;
has @.a
};
will result in a fatal compile time error, while this:
class A {
has $.a;
has @.a
multi a ($::CLASS) {
# do something here,.. I dont know what :)
}
};
will not fail.
Hope this helps :)
Stevan
Re: overloading the variable declaration process
On 2/12/06, Thomas Sandlass [EMAIL PROTECTED] wrote:
IIRC, you can always create a new method for a class, even outside of
its definition, simply by ensuring that the first parameter to be
passed in will be an object of that type:
method bark (Dog $_) { ... }
I don't think this is true unless it is a multi method, in which case
it is not actually a method of the of the class, but instead just
DWIMs because of MMD and the fact we allow an invocant calling style
freely.
Yes, the question of ownership of methods is still
somewhat unresolved. I think we need to distinguish
something I've called slots in an object from free
(multi) methods that are defined outside of the class
definition block. BTW, do the outsiders have access
to the private data slots with the $! twigil?
I think that multimethods defined outside of the scope of the class
should not have access to the classes data slots, it should use the
accessors. And those multimethods should live in the package in which
they are defined. The class implementation can stash refs to
multimethods which apply to it for optimization reasons, but this has
nothing to do with the language design itself.
As far as method name disambiguation, we should use the calling style
(invocant vs. normal function call) to determine which method to call.
I am sure there are other edge cases to be uncovered here as well, but
I can't think of them at the moment.
Stevan
