Add link to STD.pm where official documentation listed
On #perl6 Larry said that STD is a part of the specification for perl6. Would it be possible to include a link to STD.pm in the list of official documentation? There are things in STD that are not in the specifications, eg., default values for optional parameters should come after traits assigned to the parameters.
Re: spelunking in the meta-ops in STD.pm
On Sun, Jan 18, 2009 at 10:57:26PM -0800, Mark Lentczner wrote:
> I was looking through STD.pm at the parsing of metaops. I was exploring
> to see if the legal metaops for a given operator could be notated on the
> operator chart. What I found was some oddness...
Caveat: The actual autogeneration of metaop tokens needs to be
refactored somewhat. Currently any constraints are enforced
at match-time, which doesn't help trim down the list of possible
tokens. The absence of a declarative framework induces various
distortions in how the rules are formulated currently.
> op= (infix_postfix_meta_operator:sym<=>)
>
> The internal op is restricted to be not :assoc('chain') and not
> :assoc('non')... But, the various precedence groupings have a property,
> :assign on them that is never used. Yet, this property seem like just
> the thing. To my eye, :assign seems like the right set of operators that
> are expected to be used here. The current test is too liberal, allowing
> things like ,= and ==>>= (gasp!)
Agreed.
> !op (infix_prefix_meta_operator:sym)
> ---
> The internal op is restricted to be :assoc('chain'), or not have a
> default :assoc and be :bool. This seems overly defined: The only
> operators with :assoc('chain') have :bool. Like above, I think the
> internal op should be restricted on the :bool property alone.
Changed to :returns now.
> [op] (prefix_circumfix_meta_operator.reduce)
>
> This internal op is restricted to not have :assoc('non') nor be at the
> same precedence level as %conditional. That later test strikes me as
> strange. The restriction should be not having :assoc('chain') nor
> :assoc('non').
There maybe needs to be a restriction on "thunky" macro-operators.
> Now - the classes of what can be applied to what, especially considering
> other metaops, is a bit tangled:
>
> >>op -- op can be any >>op, postfix, dotty, privop, or postcircumfix
> the later is odd: what could >>(...) mean?
>
> op<< -- op can be any prefix, a [op], or another <
> I suppose these multiply applied ops might be useful? op<<<< and >>>>op
> ?
The intent was to restrict any kind of recursion for something that must
be recognized by LTM, where recursion means revisiting the same metaop.
I'd like all other allowed compositions of metaops, though. However,
the LTM is not yet powerful enough to handle that many tokens.
> op=, !op, >>op<< -- op can only be a (simple) infix operator
>
> [op], XopX -- op can an infix, or !op or XopX or >>op<<
> or, put another way, any simple or complex infix op, except op=
>
> I understand why op= and !op have highly restricted internal op sets.
> But why should >>op<< be so restricted as well? It means that >><=<<
> and >>~~<< are legal, but >>!<=<< and >>!~~<< are not.
The intent is to allow these eventually.
> And, if the prefix and postfix hyper metaops can be nested... then why
> not the infix: >>>>+<<<< anybody? (Not, mind you, that *I* would
> advocate for them, or such exotic beasts as [X>>+<>>>+<<<< are disallowed because you can't use recursive
patterns in the LTM if it is to remain in the realm of regular
languages. [X>>+< Lastly, the token for [x] (prefix_circumfix_meta_operator.reduce) has an
> oddity that it allows an optional trailing << (acutally, only the
> Unicode version of that!). I'm not sure why the prefix hyper metaop is
> parsed here... especially since the code for token PRE clearly parses
> this construction.
Again has to do with faking out the LTM pattern generator for now. Should
get better later.
Larry
small patch to STD.pm
This fixes a typo and enables X>>+< X | X -| X +| X ] = $; }>
spelunking in the meta-ops in STD.pm
I was looking through STD.pm at the parsing of metaops. I was
exploring to see if the legal metaops for a given operator could be
notated on the operator chart. What I found was some oddness...
op= (infix_postfix_meta_operator:sym<=>)
The internal op is restricted to be not :assoc('chain') and
not :assoc('non')... But, the various precedence groupings have a
property, :assign on them that is never used. Yet, this property seem
like just the thing. To my eye, :assign seems like the right set of
operators that are expected to be used here. The current test is too
liberal, allowing things like ,= and ==>>= (gasp!)
!op (infix_prefix_meta_operator:sym)
---
The internal op is restricted to be :assoc('chain'), or not have a
default :assoc and be :bool. This seems overly defined: The only
operators with :assoc('chain') have :bool. Like above, I think the
internal op should be restricted on the :bool property alone.
[op] (prefix_circumfix_meta_operator.reduce)
This internal op is restricted to not have :assoc('non') nor be at the
same precedence level as %conditional. That later test strikes me as
strange. The restriction should be not having :assoc('chain')
nor :assoc('non').
Now - the classes of what can be applied to what, especially
considering other metaops, is a bit tangled:
>>op -- op can be any >>op, postfix, dotty, privop, or postcircumfix
the later is odd: what could >>(...) mean?
op<< -- op can be any prefix, a [op], or another <I suppose these multiply applied ops might be useful? op<<<< and
>>>>op ?
op=, !op, >>op<< -- op can only be a (simple) infix operator
[op], XopX -- op can an infix, or !op or XopX or >>op<<
or, put another way, any simple or complex infix op, except op=
I understand why op= and !op have highly restricted internal op sets.
But why should >>op<< be so restricted as well? It means that >><=<<
and >>~~<< are legal, but >>!<=<< and >>!~~<< are not.
And, if the prefix and postfix hyper metaops can be nested... then why
not the infix: >>>>+<<<< anybody? (Not, mind you, that *I* would
advocate for them, or such exotic beasts as [X>>+<
Lastly, the token for [x] (prefix_circumfix_meta_operator.reduce) has
an oddity that it allows an optional trailing << (acutally, only the
Unicode version of that!). I'm not sure why the prefix hyper metaop is
parsed here... especially since the code for token PRE clearly parses
this construction.
- Mark
Re: Project idea: Perl 6 syntax hilighting with STD.pm
John M. Dlugosz wrote: > Does that mean there is a tool I can use to apply STD.pm to syntax-check > my examples or ask questions of it? Can you point to that? in the pugs repository: $ cd src/perl6 $ make $ ./tryfile $filename That assumes a perl 5.10 in /usr/local/bin/perl HTH, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Project idea: Perl 6 syntax hilighting with STD.pm
Does that mean there is a tool I can use to apply STD.pm to syntax-check my examples or ask questions of it? Can you point to that? --John Moritz Lenz wrote: Since now STD.pm parses most Perl 6 code now, and spits out a parse tree in YAML, a brave soul might want to write a syntax hilighter for Perl 6. I volunteer to write a HTML backend for it ;-) I think it basically involves walking the YAML generated tree, keep track of a few variables and emit a linear list from that. Maybe looking a bit into STD.pm to find out what some token names actually mean. I'm a bit short on tuits and motivation, but if anyone wants to write a shiny tool, this might be a nice place to start. (And if it helps to identify some mis-parses from STD.pm it will also help $Larry ;-) Cheers, Moritz
Re: Does STD.pm handle this?
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
sub foo ($x) {...}
$x = &foo.new(3);
I don't understand your point. Are you thinking of .callwith or
postcircumfix<( )> methods on the Code object?
No, I think of foo not as a Code object but as a class that
does Code. Invoking foo means instanciating the Code class.
That is the above stores an uninvoked invocation of foo in $x.
Obviously you can invoke it as $x() later to get out what
foo(3) would. I think you can continue this with
No, &foo is an =instance= of class Routine (or something further derived
from it), and Routine does Code.
Your example of making an uninvoked call is contradicted by the
Synopses. It is explained under "currying".
--John
Re: Does STD.pm handle this?
HaloO,
John M. Dlugosz wrote:
But Newname is not declared yet!
No, but that is the same as with other sigiled terms.
You can also do funny things like
::*Num ::= Complex;
The spec doesn't define namespaces to be protected in any
way. The above is naturally limited to the compile run,
though. Now the question is what repercussions
::*Num := Complex;
has at runtime? Is it allowed? Note that with :: there seems
to be a syntactic distinction between lvalues and rvalues
that other sigils don't have:
$x = 3; # x as lvalue
$y = x; # x as rvalue
This even doesn't work with code variables
&x = 3; # needs {3} or Code 3, but why is that not implicit?
$y = x;
where I find it quite intuitive. IOW, there are some
intrinsic type checks at compile type.
sub foo ($x) {...}
$x = &foo.new(3);
I don't understand your point. Are you thinking of .callwith or
postcircumfix<( )> methods on the Code object?
No, I think of foo not as a Code object but as a class that
does Code. Invoking foo means instanciating the Code class.
That is the above stores an uninvoked invocation of foo in $x.
Obviously you can invoke it as $x() later to get out what
foo(3) would. I think you can continue this with
$y = $x + 1;
which has to put an uninvoke invocation of infix:<+> into
$y and so on. You can call that lazy computation. Such an
uncalled computation can be collapsed with $y().
BTW, what is the official syntax for coroutines now?
I see no mention of the yield builtin in S06.
class foo ($x) {...} # constructor syntax?
$y = ::foo.new(3);# perhaps also: ::foo(3)
$z = foo 3; # ambiguous or &foo?
If you wanted more than one constructor you'd need to prefix
it with multi.
That doesn't look like Perl 6 at all. The parens after class foo is not
part of the grammar. I think what you are showing on the second line
would be a definition for method new inside of class foo. I get you're
trying to explain how subs are like classes, but I'm not following.
I try more to describe how bare words work. You can overload the bare
word foo with two things: ::foo and &foo. After first usage with the
sigil it's available without. The & form is even more flexible. It is
provisionally parsed as list prefix. And you can call ::foo as a list
prefix as well. So which takes precedence if both are defined?
Type as a list operator is type conversion. The parens are just
grouping, as in any list operator.
But what else should it be than a constructor call?
Type would mean Type{'blah'}
No. That would require Type to be a term.
sub foo {...}
foo; # syntax error or special type meaning
foo ; # calls foo with @_[0] :=
foo .; # calls foo with @_[0] := $CALLER::_.
foo::; # pulls out a from lexical namespace of foo
The last line uses postfix:<::> not sigil:<::>.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
Re: Does STD.pm handle this?
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
I guess not. But
::Newname ::= OldTypeName;
should work. The type system is a runtime overlay to
the value system. This is reflected in the source by
putting types and values into different syntactic slots.
You cannot mix these!
But Newname is not declared yet!
I unify class and code conceptually and Perl 6 might
unify them actually. That is I think invoking a sub
essentially means:
sub foo ($x) {...}
$x = &foo.new(3);
I don't understand your point. Are you thinking of .callwith or
postcircumfix<( )> methods on the Code object?
class foo ($x) {...} # constructor syntax?
$y = ::foo.new(3);# perhaps also: ::foo(3)
$z = foo 3; # ambiguous or &foo?
If you wanted more than one constructor you'd need to prefix
it with multi.
That doesn't look like Perl 6 at all. The parens after class foo is not
part of the grammar. I think what you are showing on the second line
would be a definition for method new inside of class foo. I get you're
trying to explain how subs are like classes, but I'm not following.
BTW, I wonder why S12 is wasting {} for parent class construction:
class Dog is Animal {...}
my $pet = Dog.new( :name, Animal{ :blood, :legs(4) } );
Wouldn't parens be sufficient? Looks like Type{} now means protoobject
construction and Type() means concrete object construction. And Type[]
means type construction. So what exactly can one do with a protoobject?
And what is a protoinvocation of a sub? When is it evaluated?
Finally I wonder why we didn't give a meaning to Type<>? Does that
look too much like C++, C# or Java templates?
Regards, TSa.
Type as a list operator is type conversion. The parens are just
grouping, as in any list operator. Type would mean Type{'blah'}
from the usual correspondence of <> indexing to hash indexing without
quotes. Likewise you also have the frenchquote form which is the same
with interpolation. So that doesn't mean anything in the situation, but
<> are "taken" in a sense.
--John
Re: Does STD.pm handle this?
HaloO,
John M. Dlugosz wrote:
sub GetType (-->Type) { ... }
my ::RunTimeType := GetType;
I think my declares value variables which means you need
a sigil:
my ::RunTimeType $ := GetType;
and of course you capture the runtime type of the
return value of GetType. If you write that as
my ::RunTimeType $ := &GetType;
you get the type of &GetType itself that is :(-->Type).
Also, is this the normal way of making typedefs?
my ::Newname := OldTypeName;
I guess not. But
::Newname ::= OldTypeName;
should work. The type system is a runtime overlay to
the value system. This is reflected in the source by
putting types and values into different syntactic slots.
You cannot mix these!
I unify class and code conceptually and Perl 6 might
unify them actually. That is I think invoking a sub
essentially means:
sub foo ($x) {...}
$x = &foo.new(3);
class foo ($x) {...} # constructor syntax?
$y = ::foo.new(3);# perhaps also: ::foo(3)
$z = foo 3; # ambiguous or &foo?
If you wanted more than one constructor you'd need to prefix
it with multi.
BTW, I wonder why S12 is wasting {} for parent class construction:
class Dog is Animal {...}
my $pet = Dog.new( :name, Animal{ :blood, :legs(4) } );
Wouldn't parens be sufficient? Looks like Type{} now means protoobject
construction and Type() means concrete object construction. And Type[]
means type construction. So what exactly can one do with a protoobject?
And what is a protoinvocation of a sub? When is it evaluated?
Finally I wonder why we didn't give a meaning to Type<>? Does that
look too much like C++, C# or Java templates?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
Does STD.pm handle this?
sub GetType (-->Type) { ... }
my ::RunTimeType := GetType;
This is clearly permitted by the prose, that " ::x may be bound to any object
that does the Abstraction role, such as a typename, package, module, class,
role, grammar, or any other protoobject with .HOW hooks."
But the syntax might think that is the value type and complain that no variable
followed. Can someone make sure the grammar handles this, so we can bug Larry
if it doesn't?
Also, is this the normal way of making typedefs?
my ::Newname := OldTypeName;
(or constant instead of my?)
or is there some other syntax specific to the task?
Re: STD.pm
On Sat, Apr 05, 2008 at 07:59:36PM -, John M. Dlugosz wrote: : I'm trying to fathom STD.pm. : : Maybe someone can help me trace through this one? : : How is : $obj!privA = 1; : parsed? : : Reading expect_term, it trys , then sees the "$" and commits to the decision, reads "obj" as a , then checks for a ".", but doesn't have similar logic for "!". You probably need to svn up. I only just added dotty: yesterday. The dotty rule is called from expect_term via the post rule. Larry
Re: STD.pm
On Sat, Apr 05, 2008 at 05:32:27PM -0500, Patrick R. Michaud wrote: > On Sat, Apr 05, 2008 at 07:59:36PM -, John M. Dlugosz wrote: > > I'm trying to fathom STD.pm. > > > > Maybe someone can help me trace through this one? > > > > How is > > $obj!privA = 1; > > parsed? > > > > Reading expect_term, it trys , then sees the > > "$" and commits to the decision, reads "obj" as a , > > then checks for a ".", but doesn't have similar logic for "!". > > I'm not sure what you mean by "then checks for a '.'" -- I don't > the dot in the rule isn't the same as the method dot. Erg, I mis-edited this. The dot that appears in the rule isn't the normal method dot -- I think it handles things like C< $.( ... ) > and C< @.( ... ) >. Pm
Re: STD.pm
On Sat, Apr 05, 2008 at 07:59:36PM -, John M. Dlugosz wrote:
> I'm trying to fathom STD.pm.
>
> Maybe someone can help me trace through this one?
>
> How is
> $obj!privA = 1;
> parsed?
>
> Reading expect_term, it trys , then sees the
> "$" and commits to the decision, reads "obj" as a ,
> then checks for a ".", but doesn't have similar logic for "!".
I'm not sure what you mean by "then checks for a '.'" -- I don't
the dot in the rule isn't the same as the method dot.
I think the way it parses is that we get $obj from the
=> sequence at the beginning of ,
and then !privA is parsed via the => dotty:sym sequence.
So the parse tree looks something like:
= {
= {
= {
# "$"
# "obj"
}
}
= [
[0] = {
= {
# "!"
= {
# "privA"
}
}
}
]
}
Pm
STD.pm
I'm trying to fathom STD.pm. Maybe someone can help me trace through this one? How is $obj!privA = 1; parsed? Reading expect_term, it trys , then sees the "$" and commits to the decision, reads "obj" as a , then checks for a ".", but doesn't have similar logic for "!". So it's parsed as $obj ! privA --John
Re: understanding STD.pm
On Sat, Apr 05, 2008 at 09:16:13AM -0400, Ryan Richter wrote: > On Sat, Apr 05, 2008 at 08:22:42AM -, John M. Dlugosz wrote: > > > > OK, you got me. What is the "?" used for? For example, > === $!ws_to }>. > > > > I only see that character as used in this manner (a variable name?), > > never defined (e.g. as a variable or parameter) anywhere. > > Something is choking on utf8, it should be a cent sign (242 is octal > latin1 for '?'). $? is the current match continuation. I don't think > it's specced, it's just an internal Cursor.pm thing that leaked out into > STD in a few places (I could be wrong about that, though). Heh, my reply only makes sense if your mail is first misrendered as invalid utf8 instead of latin1 which you sent it in... And my reply is even more screwed up wrt encoding, sorry for the confusion... -ryan
Re: understanding STD.pm
On Sat, Apr 05, 2008 at 08:22:42AM -, John M. Dlugosz wrote: > > OK, you got me. What is the "�" used for? For example, === $!ws_to }>. > > I only see that character as used in this manner (a variable name?), > never defined (e.g. as a variable or parameter) anywhere. Something is choking on utf8, it should be a cent sign (242 is octal latin1 for '�'). $� is the current match continuation. I don't think it's specced, it's just an internal Cursor.pm thing that leaked out into STD in a few places (I could be wrong about that, though). -ryan
understanding STD.pm
OK, you got me. What is the "¢" used for? For example, . I only see that character as used in this manner (a variable name?), never defined (e.g. as a variable or parameter) anywhere. --John
