Re: comprehensive list of perl6 rule tokens
On Thu, Jun 02, 2005 at 09:19:22PM +0200, "TSa (Thomas Sandlaß)" wrote:
> >I think the state object ought to have some sort of base type --
> >is it Grammar? Rule? If we say it's a "Rule", then we're
> >effectively saying that "applying a Rule to a target results
> >in a Rule object containing the state of the match", which just
> >sounds completely wrong to my ears/eyes (even though it may in
> >fact be correct).
>
> It sounds perfectly to my ears. You should think of ordinary
> subs as classes and calls to them as instances of that class.
> The environment created at runtime for such an invokation actually
> *is* a sub object. [...]
Okay, viewing it that way makes me quite a bit more comfortable with it.
I've also re-read parts of A05 (and S12 and S06) that seem to help
to clear things up a bit. Specifically, A05 says
In this case a rule is simply a method in a grammar class,
and a grammar class is any class derived implicitly or
explicitly from the universal [Rule] grammar class.
I take from this that
grammar Foo { ... }
creates a class Foo derived from Rule, and any rules declared in the
braces are (class) methods of Foo that create instances of Foo.
Combined with other statements, this also means that match objects are
instances of either Rule or the grammar method used to create them.
I also guess this means we really don't need a C type
as mentioned in S06, since that's being covered by Rule. Or
perhaps Grammar is an abstract subclass of Rule and the C
statement derives new grammars from Grammar.
A05 also mentions
The built-in regex assertions like C<< >> are
really just calls to methods in the [Rule] class.
which works well for me for the time being.
So, returning to invocants, and throwing in lexically scoped rules
to boot, consider the following. (This may more properly belong on
p6c, but since the thread started here I'll keep it here for a message
or two until it becomes obvious it belongs somewhere else.)
grammar Foo {
rule alpha { <[abcdef]> }
rule beta { + + }
}
my rule alpha { <[uvwxyz]> }
my rule beta { + + }
m :w / /
We have to get the code for each of the two "beta" rules to properly
dispatch to the appropriate grammar-scoped or lexically-scoped rule,
and get the appropriate invocant. The process appears to be:
1. If the subrule is scoped (e.g., ), then dispatch
to Foo.beta(target,pos).
2. If the subrule is not scoped (e.g., ), then look for
a lexically-scoped subrule of the same name -- i.e.,
beta(target, pos) and call that if it exists. Otherwise,
call $/.beta(target, pos).
In each case, the subrule returns a match object of the same type
as its "invocant".
Or something like that.
Pm
Re: Transparent / Opaque references
On Thu, Jun 02, 2005 at 10:45:45PM +0200, Juerd wrote: > If we allow "sub .foo", "sub :foo" comes naturally, and another > asymmetry is gone. > > It would also allow "multi sub" and "multi method" to simply become > "multi". I _really_ like the explicit 'method' name that methods have. Calling them subs doesn't make sense to me. -- wolverian signature.asc Description: Digital signature
Re: Transparent / Opaque references
"TSa (Thomas Sandlaß)" skribis 2005-06-02 22:22 (+0200):
> The only thing that is a bit unclear to me is if the dot is part of the
> operator name---like a sigil---or purely syntactical. A method is e.g.
> also not defined with the dot:
> class Blahh
> {
>method .example ( $non_invocant ) {...}
> }
Good question.
Attributes are declared with a dot:
has $.foo;
And the colon in private method names appears to be part of the name:
method :foo { ... }
However, while $:foo corresponds to :foo, $.foo does so to foo, not
.foo
(I personally hate the weird thing with private attributes and methods.)
Every postcircumfix operator we have can be used with and without the
dot, and it's unclear if the dot is part of the name.
While with reduce we include the dot
[.{}]
the operator itself is declared without:
&postcircumfix:<{ }>
Hm, back to methods: in Perl 5 I used to make the mistake of writing
"sub .foo" when I meant what we now call "method foo".
If we allow "sub .foo", "sub :foo" comes naturally, and another
asymmetry is gone.
It would also allow "multi sub" and "multi method" to simply become
"multi".
This leaves submethods, and perhaps they just need a third character,
that joins . and :. I have no idea what character would be useful, but
assuming >, it would also give $>foo, which would be to attributes what
submethods are to methods.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Transparent / Opaque references
HaloO Juerd,
you wrote:
Except that () doesn't return a reference to an anonymous scalar of the
list it surrounds.
Of course not. The inside of the .() call operator has type
Signature and the dispatch goes to the implementation that has
the closest type distance to the types of the actual args. This
is the same for all the postcircumfix ops (), [], {}, <> and «».
In our case here the type of the non-invocant part of the Signature
is simply Void. The single invocant's type to the left of the operator
is determining the receiving method implementation. The return type of
this method and the rhs are used in dispatching &infix:{'='}. This
is how type systems based on MMD work. How much of this dispatching
can be pre-calculated at compile time is irrelevant for the semantics.
The only thing that is a bit unclear to me is if the dot is part of the
operator name---like a sigil---or purely syntactical. A method is e.g.
also not defined with the dot:
class Blahh
{
method .example ( $non_invocant ) {...}
}
--
TSa (Thomas Sandlaß)
Re: Transparent / Opaque references
"TSa (Thomas Sandlaß)" skribis 2005-06-02 21:30 (+0200):
> And it nicely lines up with $y[], $y{}, @a[], %h{} etc. as
> dereferential expressions.
Except that () doesn't return a reference to an anonymous scalar of the
list it surrounds.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Transparent / Opaque references
Juerd wrote:
$y() = 7;
No, sorry, that looks to me as if $y is a reference to an lvalue sub,
not like any form of referencing of scalars.
Well, it is a reference to an lvalue sub if it is just that :)
As unspecificly typed as it stands there it could be anything
that reacts to &postfix:<()>
And it nicely lines up with $y[], $y{}, @a[], %h{} etc. as
dereferential expressions.
--
TSa (Thomas Sandlaß)
Re: comprehensive list of perl6 rule tokens
Patrick R. Michaud wrote: Alas, it doesn't seem to be quite that straightforward. Or maybe it is, and I'm just not seeing it yet. So, I'll just "think out loud" here for a bit... I like it if that is happening on the list instead of off-list. Thanks. I think the state object ought to have some sort of base type -- is it Grammar? Rule? If we say it's a "Rule", then we're effectively saying that "applying a Rule to a target results in a Rule object containing the state of the match", which just sounds completely wrong to my ears/eyes (even though it may in fact be correct). It sounds perfectly to my ears. You should think of ordinary subs as classes and calls to them as instances of that class. The environment created at runtime for such an invokation actually *is* a sub object. The code you write is a class specifying the behaviour of running instances. In a multi-threaded application there might be several long-living invocations/instances that spawn other shorter living ones. But this is the same as with dynamic memory allocation for data objects. Suspended coroutines are just the same as data objects that no code instance is working with. The CPS of Parrot makes the implementation of this unification of code and data instances easier than caring for a central call stack in other VMs or real silicon. The programming language rules are written in is of course a sublanguage of Perl 6---but that you know better than I. I'll be appreciative of any illumination that others can provide to the above, especially from @Larry. Sorry, I'm neither one(@Larry) nor a good Illuminati ;) -- TSa (Thomas Sandlaß)
Re: Transparent / Opaque references
"TSa (Thomas Sandlaß)" skribis 2005-06-02 20:36 (+0200): > Might it be applicable to use .() as the dereferencer > of scalar variables that derefs to the next none(Ref) > type and if that is a Code it dispatches to it as expected? Or perhaps postfix $, to deref recursively. my $foo = 5; my $bar = \\$foo; print $bar$; # 5 Just don't call your variable $Id ;) Or of course a very simple .deref method. I still think the feature isn't needed at all. > $y() = 7; No, sorry, that looks to me as if $y is a reference to an lvalue sub, not like any form of referencing of scalars. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Transparent / Opaque references
Luke Palmer wrote: When we heard that Larry didn't acutally want $$foo to infinitely dereference, some of us were overjoyed, and others severely disappointed. Both transparent dereferencing (infinite $$foo) and opaque dereferencing (one-level $$foo) have their uses, but they are definitely distinct. I guess a syntax like the reduce meta operator [$]$ref = whatever(); doesn't work for the $ sigil because it firstly is no operator and secondly unary. So I join the single $-single-steps-party. Might it be applicable to use .() as the dereferencer of scalar variables that derefs to the next none(Ref) type and if that is a Code it dispatches to it as expected? This nicely gives: $x = 3 $y = \$x; $y() = 7; say $x; # prints 7 $y = 23; # detaches from $x say $x; # still prints 7 One detail is that lvalue subs without params must be taken care of. But they'll have a proxy anyway to handle assignment. Another general thing is of course that explicitly constant Refs shall not be applicable as a lhs of assignment. This applies to chains of prefixed $ as well. -- TSa (Thomas Sandlaß)
Re: comprehensive list of perl6 rule tokens
On Thu, Jun 02, 2005 at 09:14:33AM +0200, "TSa (Thomas Sandlaß)" wrote: > Patrick R. Michaud wrote: > >Of course, there are other "implicit" parameters that are given > >to a rule -- the target string to be matched and an initial > >starting position. But I think some of those details are still > >being worked out. > > Wasn't it said that rules have the current match object/state > as invocant? I would assume that everything else can be found > through it? Actually the mnemonics that $/ is the match and > methods on $?SELF are called with ./method fits. The only > remaining thing is to define the method set of the Match class. Alas, it doesn't seem to be quite that straightforward. Or maybe it is, and I'm just not seeing it yet. So, I'll just "think out loud" here for a bit... If the current match object/state ($/) is the invocant of the rule, then in order for rule inheritance to work properly $/ must be able to be an instance of a Grammar. A05 explicitly recognizes this possibility when it says "the state object may in fact be an instance of a grammar class". If that's the case, we might not need a separate C class, and we just place the methods needed for inspecting "match objects" into the Grammar class. But somehow my brain just has trouble accepting that applying a rule to a target returns an "instance of a Grammar". The wording seems all wrong, or perhaps I just need to adjust what I think of when I see the word "Grammar". Getting rule inheritance to work properly is a bit tricky. When confronted with something like "label: x = y + z" ~~ rx :w / (\w+) \: / we have to create at least two match objects, and if we say that the match objects are the rule invocants, then the grammar engine has to be smart enough to recognize that the match object it creates to use as the invocant of is an instance of grammar Foo. Or, perhaps Foo::expr and all rules in Foo are really constructors of some sort that build Foo objects--that seems more logical. But if we say that Foo::expr is a sub or method that constructs Foo objects (as opposed to having a pre-existing invocant), then Foo::expr needs to have the target string and starting position available to it somehow, as I mentioned in my previous message. On another topic, what do we do with rules that aren't members of a grammar? A05 says: Within a closure, C<$_> represents the current state of the current regex, and by extension, the current state of all the regexes participating in the current match. (The type of the state object is the current grammar class, which may be an anonymous type if the current grammar has no name. If the regex is not a member of a grammar, it's of type RULE.) I suspect the first sentence is out of date -- that C<$_> above is now really C<$/> (the match object). Since in the case of a bare rule we don't have a "current grammar", what can we say about the type of the state object beyond "it may be an anonymous type"? I think the state object ought to have some sort of base type -- is it Grammar? Rule? If we say it's a "Rule", then we're effectively saying that "applying a Rule to a target results in a Rule object containing the state of the match", which just sounds completely wrong to my ears/eyes (even though it may in fact be correct). Or perhaps all of this is to resolved using roles, mixins, or multiple superclasses. But to get back to my original statement that "some of the details are still being worked out", I find that A05 is somewhat speculative on many of the details of how grammars, inheritance, state objects, and rules will interact, and S05 is practically silent on the topic. So, there's definitely some work to do. And of course we have to figure out how to map all of this into what Parrot has available, or update Parrot to provide what we need to do this. :-) I'll be appreciative of any illumination that others can provide to the above, especially from @Larry. Pm
Re: date and time formatting
Paul Seamons skribis 2005-06-02 9:43 (-0600): > localtime() and gmtime() seem fairly core to me. The array contexts are > simple, and the scalar context is an RFC valid string. Nothing too heavy s/array context/list context/ Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: date and time formatting
> So, if we continue following this API, Perl6 core will contain time(), > but no localtime() nor gmtime(). The Date module will provide human > readable date and time strings, and basic date math. localtime() and gmtime() seem fairly core to me. The array contexts are simple, and the scalar context is an RFC valid string. Nothing too heavy there. The time() function is "typically" only moderately useful without localtime(). Paul
Revisiting .chars (and friends) in list context
All: I would like to revisit the following question as there was no decision reached AFAICT. http://groups.google.ca/group/perl.perl6.language/browse_thread/thread/766c1b32c57a56f6/3296f0d6cad75548?q=list+context+.chars&rnum=1&hl=en#3296f0d6cad75548 What I would like to be able to do is: my $str = 'hello'; my @chars = $str.chars; # There were some good points raised in that thread that I think are valid, but I think it digressed from the intent of the original question. Perhaps that is because "unicode" prefaced chars which clouded the waters. I don't know anything about unicode and leaving the hard choices for doing the "right thing" up to you all. Whatever the "right thing" is, will there be a way to do what my code snippet showed? Cheers, Joshua Gatcomb a.k.a. L~R
Re: Empty hash
On 6/2/05, "TSa (Thomas Sandlaß)" <[EMAIL PROTECTED]> wrote:
> Luke Palmer wrote:
> > Why did we change { %hash } from making a shallow copy of a hash to
> > the code that returns %hash?
>
> Sorry, I don't understand this question. Do you want 'shallow copy'
> to mean 'take a ref'? Or Parrot/Pugs level COW?
I think he means "Why does it produce a Code (which happens to return
%hash), instead of a (ref to a) new hash that starts out with the same
k/v pairs as %hash, but thereafter can be modified independently?"
Stuart
Re: Empty hash
Luke Palmer wrote:
Should {} be an empty hash rather than an empty code?
Does it matter? More interesting is the question what it returns
or evaluates to if it's a block. Actually with my idea of List
beeing a subtype of Code the parse time recognition of blocks
as List of Pair has no implication for the semantics! It falls
into the category of optimizations that can be performed if the
involved types can be determined at compile time.
Thus assigning that to a plain % sigiled variable expression would
kick out the previous content and store a freshly created undef
under a key calculated from the incoming undef. Which in my eyes
is pretty useless. In particular if the outcome is that +%hash == 1
instead of defining that
%hash = {};
clears the content of the hash and that +%hash == 0. But the fans
of extra levels of indirection in the @array case might like to get
a default key like '' or 0 beeing used, such that the particular
undef from the {} of the rhs of the assignment can be retrieved with
%hash<0><0>. For an arbitrary undef any non-existing index suffices :)
Why did we change { %hash } from making a shallow copy of a hash to
the code that returns %hash?
Sorry, I don't understand this question. Do you want 'shallow copy'
to mean 'take a ref'? Or Parrot/Pugs level COW?
Are you alluding to the referential semantics discussion?
--
TSa (Thomas Sandlaß)
Re: Empty hash
On 6/1/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Should {} be an empty hash rather than an empty code?
Given that an empty hashref is probably much more useful than an empty
block, I propose that {} be an empty hash and {;} be an empty block.
This mirrors the fact that (AFAIK) { $_ => 1 } is a hash and { $_ =>
1; } is a block.
Alternatively, it could be a special hash that can also be called (and
which does nothing), but I doubt that's useful or desirable.
Stuart
[Patch] Re: Unicode Operators cheatsheet, please!
Rob Kinyon wrote: > xOn 5/31/05, Sam Vilain <[EMAIL PROTECTED]> wrote: >> Rob Kinyon wrote: >> > I would love to see a document (one per editor) that describes the >> > Unicode characters in use and how to make them. The Set implementation >> > in Pugs uses (at last count) 20 different Unicode characters as >> > operators. >> >> I have updated the unicode quickref, and started a Perlmonks discussion >> node for this to be explored - see >> http://www.perlmonks.org/index.pl?node_id=462246 > > As I replied on Perlmonks, it would be more helpful if the Compose > keys were listed and not just the ASCII versions. Plus, a quick primer > on how to enable Unicode in your favorite editor. I don't know about > Emacs, but the Vim documentation on multibyte is difficult to work > with, at best. Well, :help digraph isn't particularly bad, though the included table only covers latin-1. The canonical source is RFC1345. But I've attached a patch for the set symbols that have them. > Thanks, > Rob Index: docs/quickref/unicode === --- docs/quickref/unicode (revision 4305) +++ docs/quickref/unicode (working copy) @@ -21,6 +21,10 @@ Note that the compose combinations here are an X11R6 standard, and do not necessarily correspond to the compose combinations available when you use your "compose" key. + +The digraphs used in vim come from "Character Mnemonics & Character Sets", +RFC1345 (http://www.ietf.org/rfc/rfc1345.txt). After doing :set digraph, +the digraph ^k A B may also be entered as A B. Unicode ASCIIkey sequence charfallbackVimEmacs Unix Compose Key combination @@ -30,22 +34,22 @@ ¥ Y ^k Y e C-x 8 Y Compose Y = Set.pm operators (included for reference): -≠ != -∩ * -∪ + +≠ != ^k ! = +∩ * ^k ( U +∪ + ^k ) U ∖ - -⊂ < -⊃ > -⊆ <= -⊇ >= -⊄ !( $a < $b ) +⊂ < ^k ( C +⊃ > ^k ) C +⊆ <= ^k ( _ +⊇ >= ^k ) _ +⊄ !( $a < $b ) ⊅ !( $a > $b ) ⊈ !( $a <= $b ) ⊉ !( $a >= $b ) -⊊ < +⊊ < ⊋ > -∋/∍ $a.includes($b) -∈/∊ $b.includes($a) +∋/∍ $a.includes($b) ^k ) - +∈/∊ $b.includes($a) ^k ( - ∌!$a.includes($b) ∉!$b.includes($a) @@ -58,20 +62,20 @@ So, these *might* be considered not too awful; -× * -¬ ! +× * ^k * X +¬ ! ^k N O ∕ / ≡ =:= ≔ := ⩴ or ≝ ::= - ≈ or ≊~~ + ≈ or ≊~~ ^k ? 2 … ... -√ sqrt() -∧ && -∨ || +√ sqrt() ^k R T +∧ && ^k A N +∨ || ^k O R ∣ mod (? bit of a stretch, perhaps) - ⌈$x⌉ceil($x) - ⌊$x⌋floor($x) + ⌈$x⌉ceil($x) ^k 7 + ⌊$x⌋floor($x)^k 7 7 However I think it is a BAD idea that the following unicode characters
Re: comprehensive list of perl6 rule tokens
Patrick R. Michaud wrote: Of course, there are other "implicit" parameters that are given to a rule -- the target string to be matched and an initial starting position. But I think some of those details are still being worked out. Wasn't it said that rules have the current match object/state as invocant? I would assume that everything else can be found through it? Actually the mnemonics that $/ is the match and methods on $?SELF are called with ./method fits. The only remaining thing is to define the method set of the Match class. -- TSa (Thomas Sandlaß)
Re: My presentation on last weekend
On Wed, 01 Jun 2005 13:11:34 -0400, BÁRTHÁZI András <[EMAIL PROTECTED]> wrote: Hi, I just would like to share it with you. We had a weekend at the lake Balaton on the last weekend, where I had a talk about Perl 6. The guys liked it (the girls had sunbath during the event :), and one of them (Poetro) said the summary: then we can say, that Perl 6 is an "operator oriented language"? We agreed. As do I! I love it in fact :) Bye, Andras Matt
