Re: C<::> in rules
Larry Wall wrote: Speaking of which, it seems to me that :p and :c should allow an argument that says where to start relative to the current position. In other words, :p means :p(0) and :c means :c(0). I could also see uses for :p(-1) and :p(+1). Isn't that slightly inconsistent with :p meaning :p(1) the so-called "real winner for passing boolean options" of A12? -- TSa
Re: split /(..)*/, 1234567890
Rick Delaney wrote:
On Fri, May 13, 2005 at 04:05:23AM +0800, Autrijus Tang wrote:
On Thu, May 12, 2005 at 12:01:59PM -0700, Larry Wall wrote:
Yes, though I would think of it more generally as
('', $0, '', $0, '', $0, ...)
where in this case it just happens to be
('', $0)
and $0 expands to ['12','34','56','78','90'] if you treat it as an array.
I don't understand this comment. The $0 here is an array of
match-objects and when treated as array it returns an array of
match-objects, not an array of strings. (see below)
Thanks, implemented as such.
pugs> map { ref $_ } split /(..)*/, 1234567890
(::Str, ::Array::Const)
Sorry if I'm getting ahead of the implementation but if it is returning
$0 then shouldn't ref($0) return ::Rule::Result or somesuch? It would
just look like an ::Array::Const if you treat it as such.
With pugs (r2917) this doesn't return an Array of Strings but an Array
of Match-objects:
pugs> map { ref $_ } split /(..)*/, 1234567890
(::Str, ::Array::Const)
pugs> map { ref $_ } [split /(..)*/, 1234567890][1]
(::Match, ::Match, ::Match, ::Match, ::Match)
pugs> map { ~$_ } [split /(..)*/, 1234567890][1]
('12', '34', '56', '78', '90')
pugs> map { $_.from } [split /(..)*/, 1234567890][1]
(0, 2, 4, 6, 8)
--
Markus Laire
Re: C<::> in rules
TSa (Thomas Sandlaß) kirjoitti: Larry Wall wrote: Speaking of which, it seems to me that :p and :c should allow an argument that says where to start relative to the current position. In other words, :p means :p(0) and :c means :c(0). I could also see uses for :p(-1) and :p(+1). Isn't that slightly inconsistent with :p meaning :p(1) the so-called "real winner for passing boolean options" of A12? Perhaps spec should be changed so that :p means :p(bool::true) or :p(?1) and not :p(1) -- Markus Laire
Re: split /(..)*/, 1234567890
On Thu, May 12, 2005 at 07:13:22PM +0200, Jody Belka wrote: > sepsepsepsepsepsep > | | | | | | > 11 22 33 44 55 66 > | | | | | | > field field field field field field whoops. add an extra field component in at the end of that of course. J -- Jody Belka knew (at) pimb (dot) org
Re: split /(..)*/, 1234567890
No, it's not inconsistant. Think about the simpler case split /a/,'a'
which return a list of empty strings. Now ask to keep the separators
split /(a), 'a' which will return ('', 'a', '', 'a', '', 'a', '', 'a, '',
'a'). Now look at
split /(a)/, 'aaab' which returns ('', 'a', '', 'a', '', 'a', 'b'). not no
empty string ebfore the 'b'.
In the case of split /(..)/, "12345678" all those pairs of digits are all
spearators so again you get empty strings aternating with digit pairs. If the
number of digits is odd the lat on isn't a separator so it takes the place of
the final empty string and there won;t be a empty string in the list before it,
I.e,
split /(..)/, 12345 returns (''. '12', '', '34', '5');
This is another of those cases where the computer did exactly what you ask it
to.
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
> Autrijus Tang wrote:
> > I don't know, I didn't invent that! :-)
> >
> > $ perl -le 'print join ",", split /(..)/, 123'
> > ,12,3
>
> Hmm,
>
> perl -le 'print join ",", split /(..)/, 112233445566'
> ,11,,22,,33,,44,,55,,66
>
> For longer strings it makes every other match an empt string.
> With the "Positions between chars" interpretation the above
> string is with '.' indication position:
>
> .1.1.2.2.3.3.4.4.5.5.6.6.
> 0 1 2 3 4 5 6 7 8 9 1 1 1
> 0 1 2
>
> There are two matches each at 0, 2, 4, 6, 8 and 10.
> The empty match at the end seams to be skipped because
> position 12 is after the string? And for odd numbers of
> chars the before last position doesn't produce an empty
> match:
> perl -le 'print join ",", split /(..)/, 11223'
> ,11,,22,3
>
> Am I the only one who finds that inconsistent?
> --
> TSa (Thomas Sandlaß)
>
S29: punt
Hello Rod, I was pointed to your p6l post (<4283AAC1.6060106[at]rodadams.net>) by Autrijus. I have already worked a bit on implementing/porting the functionality of builtins that I want in Perl6 (by stealing from Perl5), I can try to take over S29. > I'm finding myself in a perpetual state of either no time to work > on it, or when there is time, having insufficient brain power left to > properly assimilate everything that needs to be considered to do > any of the functions justice. Looking ahead, I do not see this > state changing for > the better in the foreseeable future. While I find myself in the same situation from time to time, I hope that I'll survive by having #perl6 support me and the wiki-style of development-via-widespread-commit... If there is somebody else who wants to uphold the banner, consider their offer instead of mine ;) -max
Re: single element lists
Larry Wall wrote: > : If yes, then (1)[0] means the same as 1.[0] and 1.[0][0][0]. If no, > : (1)[0] is a runtime error just like 1.[0] -- i.e. unable to find the > : matching .[] multisub under Int or its superclasses. > > Maybe we should just let someone poke a Subscriptable role into some > class or other to determine the behavior if they care. Why is this a role, rather then just implementing postcircumfix:«[ ]»(Whatever $self: Int $index) ? (I'd hope the error message is a bit more newbie-friendly, but that's the only special-casing I see it needing...) -=- James Mastros
Re: C<::> in rules
Markus Laire skribis 2005-05-13 11:43 (+0300): > Perhaps spec should be changed so that :p means :p(bool::true) or :p(?1) > and not :p(1) Agreed Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: C<::> in rules
On Fri, 2005-05-13 at 00:26, Patrick R. Michaud wrote:
> On Thu, May 12, 2005 at 08:56:39PM -0700, Larry Wall wrote:
> > On Thu, May 12, 2005 at 09:33:37AM -0500, Patrick R. Michaud wrote:
> > : Also, A05 proposes incorrect alternatives to the above
> > :
> > : /[:w[]foo bar]/
> > I would just like to point out that you are misreading those.
> I've been looking at patterns too long
You know, this is going to be a problem for a lot of people...
Think of this case:
/:w[foo bar|bar foo]/
I may be in the minority here, but I think we should try to avoid having
[] and () mean different things in different parts of a rule, especially
where one use is VERY common, and the other is obscure at best. I'd even
be ok with only allowing this inside our already highly magical <>:
/<:w>[foo bar|bar foo]/
and
/<:p(false)>/
and
/ <:p5['ponie']> (?{die;}) /
I checked, and while <::...> has a meaning in S05, <:...> does not, so
as long as we never allow a modifier called "::", this would work.
In fact, Larry, I think it's safe to say that <> is actually more
sought-after than that : everyone wants ;-)
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: BEGIN and lexical variables inside subroutines
Benjamin Smith wrote:
sub foo { my $x; BEGIN { $x = 3 }; say $x }
foo; foo; foo;
Currently in perl5 and pugs this prints "3\n\n\n".
Which to me looks like a mix of runtime and compile time.
Actually Dave Mitchell confirmed that this is the case in
Perl 5. I have difficulty to regard this as a feature.
I would expect $x to be undef in all three invocations.
Should BEGIN blocks be able to modify values in lexical
> variables that don't really exist yet?
I think S04 makes pretty clear, that BEGIN blocks are run
at compile time, which to me means that it runs in the
runtime---and lexical?---environment of the compiler.
And I guess it is as of now a bit underspecified what
is the API to the compiler in action. E.g. is $_ the
compiler?
And I hope that it is not possible to accidentially
mess up the internals of the compiler because code
in a BEGIN hits compiler data.
--
$TSa == all( none( @Larry ), one( @p6l ))
Re: C<::> in rules
On 5/12/05, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > I have a couple of questions regarding C< :: > in perl 6 rules. > First, a question of verification -- in > > $rule = rx :w / plane :: (\d+) | train :: (\w+) | auto :: (\S+) / ; > > "travel by plane jet train tgv today" ~~ $rule > > I think the match should fail outright, as opposed to matching "train tgv". > In other words, it acts as though one had written > > $rule = rx :w / plane ::: (\d+) | train ::: (\w+) | auto ::: (\S+) / ; > > and not > > $rule = rx :w /[ plane :: (\d+) | train :: (\w+) | auto :: (\S+) ]/ ; Those both do the same thing (which is the same as your example). When you fail over the :: after plane, it skips out of the alternation looking for something to backtrack before it. Since there is nothing, the rule fails. > Does this sound right? > > Next on my list, S05 says "It is illegal to use :: outside of > an alternation", but A05 has > > /[:w::foo bar]/ > > which leads me to believe that :: isn't illegal here even though there's > no alternation. I'd like to strike that sentence from S05 Yeah, I think using :: to break out of the innermost bracketing group is helpful even without an alternation present. > Also, A05 proposes incorrect alternatives to the above > > /[:w[]foo bar]/# null pattern illegal, use > /[:w()foo bar]/# null capture illegal, and probably undesirable > /[:w\bfoo bar]/# not exactly the same as above > > I'd like to remove those from A05, or at least put an "Update:" > note there that doesn't lead people astray. One option not > mentioned in A05 that we can add there is > > /[:wfoo bar]/ > > which is admittedly ugly. > > So, now then, on to the item that got me here in the first place. > The upshot of all of the above is that > > rx :w /foo bar/ > > is not equivalent to > > rx /:w::foo bar/ Yeah, but it is. So no problem. :-) > which may surprise a few people. The :: at the beginning of > the pattern effectively anchors the match to the beginning of > the string or the current position -- i.e., it eliminates the > implicit C< .*? > at the start of the match. Ohhh, ohh. There isn't an implicit .*? at the beginning of the match. It's more like there's an implicit .*? followed by a rule call to the match. Think of it as that we're trying to match the pattern at any position rather than there being an implicit .*?. Luke
Re: C<::> in rules
On 5/13/05, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > To use the phrase from later in your message, there's still > the "implicit .*? followed by the rule call." Since the rule > itself hasn't failed (only the group failed), we're still free to > try to match the pattern at later positions. I'm basically saying that you should treat your: $str ~~ /abc :: def | ghi :: jkl | mn :: op/; As: $rule = rx/abc :: def | ghi :: jkl | mn :: op/; $str ~~ /^ .*? <$rule>/; Which means that you fail the rule, your .*? advances to the next character and tries the rule again. Maybe I'm misunderstanding your interpretation (when in doubt, explain with code). Luke
Re: C<::> in rules
On Fri, May 13, 2005 at 03:36:50PM +, Luke Palmer wrote: > I'm basically saying that you should treat your: > $str ~~ /abc :: def | ghi :: jkl | mn :: op/; > As: > $rule = rx/abc :: def | ghi :: jkl | mn :: op/; > $str ~~ /^ .*? <$rule>/; > Which means that you fail the rule, your .*? advances to the next > character and tries the rule again. Taking this explanation literally, this would mean that $rule = rx/abc :: def | ghi :: jkl | mn :: op/; $rule = rx/abc ::: def | ghi ::: jkl | mn ::: op/; both succeed against "xyzabc---ghijkl". But even just considering the :: instance, this interpretation doesn't match what you said in your original message that :: would fail the rule without further advancing: Pm> $rule =3D rx :w / plane :: (\d+) | train :: (\w+) | auto :: (\S+) / ; Pm> "travel by plane jet train tgv today" ~~ $rule LP> When you fail over the :: after plane, it skips out of the alternation LP> looking for something to backtrack before it. Since there is nothing, LP> the rule fails. > Maybe I'm misunderstanding your interpretation (when in doubt, explain > with code). One of us is misunderstanding the other. I'll explain with code, but first let's clarify the difference. I read your first message as claiming that $r1 = rx / abc :: def | ghi :: jkl | mn :: op /; $r2 = rx / abc ::: def | ghi ::: jkl | mn ::: op /; $r3 = rx / [ abc :: def | ghi :: jkl | mn :: op ] /; are equivalent. I believe $r2 and $r3 are not equivalent. For comparison, let's first look at a slightly different example, and let's avoid subrules they don't provide the auto-advance of unanchored patterns that forms the crux of my question. First, I'm quite certain that $r2 and $r3 are different. For illustration, let's use a variation like: $q2 = rx / \w [ abc ::: def | ghi ::: jkl | mn ::: op ] /; $q3 = rx / \w [ [ abc :: def | ghi :: jkl | mn :: op ] ]/; "xyzabc---xyzghijklmno" ~~ $q2 # fails after seeing "zabc" "xyzabc---xyzghijklmno" ~~ $q3 # matches "zghijkl" The difference is precisely the difference between ::: and :: -- the former fails the rule entirely, while the latter simply fails the current group (of alternations) and tries again. With :::, an unanchored rule should also stop its process of "advancing to the next character and trying again". (Otherwise, "abefgh" ~~ rx / [ ab ::: cd | ef ::: gh ] / succeeds.) So, by analogy $r2 = rx / abc ::: def | ghi ::: jkl | mn ::: op /; $r3 = rx / [ abc :: def | ghi :: jkl | mn :: op ] /; "xyzabc---xyzghijklmno" ~~ $r2 # fails after seeing "abc" "xyzabc---xyzghijklmno" ~~ $r3 # matches "ghijkl" The :: in $r3 doesn't cause the entire rule to fail, just the group, so the match is free to backtrack and continue its "advance to the next character and try again". (What the "::" in $r3 *does* do is to tell the matching engine to not bother trying the remaining alternatives once it has seen an "abc" at this point.) So, going back to the original $r1 = rx / abc :: def | ghi :: jkl | mn :: op /; does it work like $r2 or $r3? My gut feeling is that it should work like $r2 -- i.e., that once we find an "abc" we'll fail the rule if there's not a "def" following. This also accords with what others have written in reply, when they say that all three of my expressions fail in the same way (even though they do not). However, *if* we say that :: at the top level fails the rule, that means that as things currently stand $z1 = rx :w /foo/; $z2 = rx /:w::foo/; $z3 = rx /[:w::foo]/; can be a little surprising: "hello foo" ~~ $z1 # matches "foo" "hello foo" ~~ $z2 # fails immediately upon the 'h' != 'f' "hello foo" ~~ $z3 # matches "foo" which was the point of my original post. And as I said there, I don't have a problem with this, I just wanted to make this result didn't surprise too many others. I hope this was clear enough -- if not, explain counter examples in code. :-) Pm
Re: Quick question: parens vs subroutine parameter
Larry Wall wrote: : Void context still exists and is not a form of singular or plural : context. Perhaps this should be called nullar context, although void : context works equally well for me and is not confusing because we have : no Void type. Nice, without Void we don't need the double headed pseudo type lattice needed if we were to distinguish subs that return no usefull---that is Any---value from the ones that return no value at all. So let's get just rid of Scalar and List types. How does that go with the distinction between the container and content type/class? Are all variables then implemented with Parrot level refs/pointers/PMCs and there is no need for a single element container class? Actually I would appreciate this. With the idea of the Perl6 type system having a type lattice and | meaning LUB (lowest upper bound) the apex of which would be Any. ::Any ::= Str | Num | Ref of Any | Array of Any | Hash of Any | ... The ... is dynamically updated whenever a new toplevel type is added: Any ::= Any | TheNewType. How do we name the bottom Type? None? All? The latter would nicely relate it to the & as the GLB (greatest lower bound). But OTOH, None feels more natural and is e.g. used by the Cecil folks as well. : When we really want a scalar (the thing itself), we call that Any : context or Scalar context, both forms of singular context (formerly : called scalar context). BTW, context is not meaningfull at runtime but only defines what code the compiler generates? E.g. list context would be compiled to some code that gathers the values from the involved expressions, subs and constants---into what? An Array? : What exactly is the difference between Scalar and Any? Isn't any, that I can tell. So maybe we settle on Any for the type and scalar() for the function/concept. It'd be nice if we could unify those somehow, but any() is taken. Maybe Item/item(). Just ideas from me for: no value: void, zero one value: mono, unary >1 value: poly, many -- TSa (Thomas SandlaÃ)
trait and properties thru getter/setters
There is syntax to define trait and properties but is there an API? my $b = eval '$a but true'; # setting a true property # API to do it without an eval? A trait setter probably does not make sense but for the implementer because it should not be set at run time. Incidentally, in a interactive environment it would be cool to access the documentation of variables and functions using properties. Say "doc" and "udoc" respectively for the full and one line version. -- cognominal stef
Re: trait and properties thru getter/setters
On Fri, May 13, 2005 at 06:37:50PM +, [EMAIL PROTECTED] wrote: > > > > There is syntax to define trait and properties > > but is there an API? > > > > my $b = eval '$a but true'; # setting a true property > > # API to do it without an eval? > I don't understand why you think you need the eval here? My question is more generic than my example. I may not know at compile time what is the value/trait name and its value. > > > > A trait setter probably does not make sense but for the > > implementer because it should not be set at run time. > > > > Incidentally, in a interactive environment it would be cool > > to access the documentation of variables and functions using > > properties. Say "doc" and "udoc" respectively for the full and > > one line version. > > > > -- > Mark Biggar -- cognominal stef
Re: trait and properties thru getter/setters
On 5/13/05, Stéphane Payrard <[EMAIL PROTECTED]> wrote: > > > There is syntax to define trait and properties > > > but is there an API? > > > > > > my $b = eval '$a but true'; # setting a true property > > > # API to do it without an eval? > > My question is more generic than my example. > I may not know at compile time what is the value/trait name and its > value. Well, the value's pretty easy--just pass in a variable: my $b = $a is foo($bar); As for the name, I'd be surprised if the standard symbolic-ref syntax didn't work: my $b = $a is ::($foo)($bar); -- Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker
Re: C<::> in rules
On Fri, May 13, 2005 at 11:43:42AM +0300, Markus Laire wrote:
: Perhaps spec should be changed so that :p means :p(bool::true) or :p(?1)
: and not :p(1)
I'm still not sure I believe in booleans to that extent. I suppose
we could go as far as to make it :p(0 but true). Actually, it's more
like "undef but true", if you want to be able to distinguish
sub foo (+$p = 0) { # no :p at all
say "true" if $p; # :p with no argument
$p //= 42; # :p with no argument
...
}
Or maybe it's something more like "1 but assumed". In any event, it'd
be nice to be able to distinguish :p from :p(1) somehow. Maybe the
Bool type is good enough for that. The bool type probably isn't unless
we depend on autoboxing to turn it into a Bool consistently.
Larry
Re: trait and properties thru getter/setters
On Fri, May 13, 2005 at 12:26:22PM -0700, Brent 'Dax' Royal-Gordon wrote: : Well, the value's pretty easy--just pass in a variable: : : my $b = $a is foo($bar); As we currently have it, that is not legal syntax. "is" may only be applied to declarations. You must use "does" or "but" to mixin things at run-time (where this includes the compiler's run-time bits). Larry
Re: trait and properties thru getter/setters
On Fri, May 13, 2005 at 12:31:09PM -0700, Larry Wall wrote: > On Fri, May 13, 2005 at 12:26:22PM -0700, Brent 'Dax' Royal-Gordon wrote: > : Well, the value's pretty easy--just pass in a variable: > : > : my $b = $a is foo($bar); > > As we currently have it, that is not legal syntax. "is" may only > be applied to declarations. You must use "does" or "but" to mixin > things at run-time (where this includes the compiler's run-time > bits). And what about the getter part of my question? :) > > Larry > -- cognominal stef
Re: trait and properties thru getter/setters
On 5/13/05, Larry Wall <[EMAIL PROTECTED]> wrote: > On Fri, May 13, 2005 at 12:26:22PM -0700, Brent 'Dax' Royal-Gordon wrote: > : my $b = $a is foo($bar); > > As we currently have it, that is not legal syntax. "is" may only > be applied to declarations. Sorry, think-o. I meant 'but' in my examples (and Stéphane used 'but' in his). Should I construe the fact that you didn't comment on the ::() to mean that the symref syntax works here? -- Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker
Re: C<::> in rules
On Fri, May 13, 2005 at 11:54:47AM -0500, Patrick R. Michaud wrote: : $r1 = rx / abc :: def | ghi :: jkl | mn :: op /; : $r2 = rx / abc ::: def | ghi ::: jkl | mn ::: op /; : $r3 = rx / [ abc :: def | ghi :: jkl | mn :: op ] /; I would prefer that $r1 work like $r3, not like $r2, for two reasons. First, it gives a useful distinction of meaning. Second, and more importantly, outer lexical scopes are often delimited by something other than what the inner scopes are delimited by. A file scope or an eval string is no less a block because it's not delimited by curlies. In the same way, the outer delimiters of an rx/.../ should function as if you'd said rx/[...]/. : However, *if* we say that :: at the top level fails the rule, that : means that as things currently stand : : $z1 = rx :w /foo/; : $z2 = rx /:w::foo/; : $z3 = rx /[:w::foo]/; : : can be a little surprising: : : "hello foo" ~~ $z1 # matches "foo" : "hello foo" ~~ $z2 # fails immediately upon the 'h' != 'f' : "hello foo" ~~ $z3 # matches "foo" : : which was the point of my original post. And that's the third reason. A :: at the beginning of a "group" should essentially be a no-op. By the way, I still think of it as "a group of alternatives" even if there's only one alternative, and no |. But I can see how that can be misread to imply at least two alternatives. (We're also hampered by the linguistic fact that "alternative" can mean either how many choices you have to make or how many paths are open to you. In other words, one alternative of the first sort presents you two alternatives of the second sort. And if there's no alternative, you only have one alternative. Ain't English wonderful? Anyway, :: fails the current lexical scope, not the current rule. ::: fails the current rule in a more dynamically scoped way, which is why it also fails the engine applying the implicit .*?. And of course, failure to is almost completely dynamic in scoping. It's more like unwinding an exception till you find a handler that knows it's the outer rule. Larry
Re: trait and properties thru getter/setters
On Fri, May 13, 2005 at 12:56:19PM -0700, Brent 'Dax' Royal-Gordon wrote: : Should I construe the fact that you didn't comment on the ::() to mean : that the symref syntax works here? Offhand I don't see any reason for it not to. Larry
Re: trait and properties thru getter/setters
On Fri, May 13, 2005 at 09:40:51PM +0200, Stéphane Payrard wrote: : And what about the getter part of my question? :) A12 discusses the relationship of traits and properties in great detail. Any trait's metadata can be stored as properties at compile time, and such metadata can be retrieved as properties at any time. But traits are allowed to do other things than just store metadata. Larry
Re: single element lists
On Thu, May 12, 2005 at 11:52:38PM +0200, James Mastros wrote: : Larry Wall wrote: : > : If yes, then (1)[0] means the same as 1.[0] and 1.[0][0][0]. If no, : > : (1)[0] is a runtime error just like 1.[0] -- i.e. unable to find the : > : matching .[] multisub under Int or its superclasses. : > : > Maybe we should just let someone poke a Subscriptable role into some : > class or other to determine the behavior if they care. : Why is this a role, rather then just implementing postcircumfix:«[ : ]»(Whatever $self: Int $index) ? (I'd hope the error message is a bit : more newbie-friendly, but that's the only special-casing I see it : needing...) Different abstraction level. Maybe defining the postcircumfix is exactly what the role does. Larry
Re: C<::> in rules
Larry wrote:
I'm still not sure I believe in booleans to that extent. I suppose
we could go as far as to make it :p(0 but true). Actually, it's more
like "undef but true", if you want to be able to distinguish
sub foo (+$p = 0) { # no :p at all
say "true" if $p; # :p with no argument
$p //= 42; # :p with no argument
...
}
Yes, I was thinking along the same lines. C as a default seems
to be more accurate and useful than C.
Damian
The Void type
On Fri, May 13, 2005 at 07:13:53PM +0200, "TSa (Thomas SandlaÃ)" wrote:
> Larry Wall wrote:
> >: Void context still exists and is not a form of singular or plural
> >: context. Perhaps this should be called nullar context, although void
> >: context works equally well for me and is not confusing because we have
> >: no Void type.
>
> Nice, without Void we don't need the double headed
> pseudo type lattice needed if we were to distinguish
> subs that return no usefull---that is Any---value
> from the ones that return no value at all.
Hrm. So if I have a sub that does nothing:
sub Foo { }
Is it illegal to say this?
sub Foo returns Void { }
What about:
sub Foo returns :() { }
Or do I really need to convert it to this?
sub Foo returns Any { }
Thanks,
/Autrijus/
pgps9ng6j5ciI.pgp
Description: PGP signature
Re: The Void type
Autrijus Tang wrote:
On Fri, May 13, 2005 at 07:13:53PM +0200, "TSa (Thomas Sandlaß)" wrote:
Larry Wall wrote:
: Void context still exists and is not a form of singular or plural
: context. Perhaps this should be called nullar context, although void
: context works equally well for me and is not confusing because we have
: no Void type.
Nice, without Void we don't need the double headed
pseudo type lattice needed if we were to distinguish
subs that return no usefull---that is Any---value
from the ones that return no value at all.
Hrm. So if I have a sub that does nothing:
sub Foo { }
Is it illegal to say this?
sub Foo returns Void { }
Can't we just say :
Void =:= none(Any)
and get Void for near free?
-- Rod Adams
Re: C<::> in rules
On 5/13/05, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> First, I'm quite certain that $r2 and $r3 are different. For
> illustration, let's use a variation like:
>
> $q2 = rx / \w [ abc ::: def | ghi ::: jkl | mn ::: op ] /;
> $q3 = rx / \w [ [ abc :: def | ghi :: jkl | mn :: op ] ]/;
>
> "xyzabc---xyzghijklmno" ~~ $q2 # fails after seeing "zabc"
> "xyzabc---xyzghijklmno" ~~ $q3 # matches "zghijkl"
Okay, I know where the misunderstanding is. When we use these kinds
of examples, let's not rely on the implicit matching semantic. I'm
saying that the above code is equivalent to:
# the following is a rule, so ::: backtracks out of it and no further
rule q2 { \w [ abc ::: def | ghi ::: jkl | mn ::: op ] }
rule q3 { \w [ [ abc :: def | ghi :: jkl | mn :: op ] ] }
"xyzabc---xyzghijklmno" ~~ /^ .*? /; # ::: backtracks into the .*?
"xyzabc---xyzghijklmno" ~~ /^ .*? /;
The presence of the \w does nothing, because \w doesn't backtrack.
Alternations and quantifiers backtrack when you fail beyond them, \w
just fails. You never enter the same subpattern (meant in the most
general case: .* is a subpattern, for instance) in the same state.
Something had to change behind you in order for a subpattern to be
re-entered.
I think the misunderstanding is rather simple. You keep talking like
you prepend a .*? to the rule we're matching. I think that's wrong
(and this is where I'm making a design call, so we can dispute on this
once we're clear that it's this that is being disputed). I think
there is a special rule:
rule matchanywhere($rx) { .*? <$rx> }
Which makes a *subrule call* to the rule we're matching. Therefore
::: just breaks out of that subrule, and backtracks into the .*?
again.
Because of this, I think there will be a difference between ::: and
at the top level, but not :: and :::.
Luke
Object Numify/Stringify-ing to Unique values
Hello all. In the processing of working with mugwump's shiny new perl6 OO Set.pm. I realized that we do not currently have a way to uniquely identify objects in Pugs like the way we have in perl5 (object stringification). So I asked Autrijus, and he promptly implemented a rudimentary object numification scheme, and requested I query the @Larry as to how this should really behave. So I ask ye, oh wise and powerful @Larry How is it we shall uniquely identify our objects??? Please give us a sign? your humble and over-(tired & caffinated) servent, Stevan ... sorry, it has been a long day :)
Re: Object Numify/Stringify-ing to Unique values
On Fri, May 13, 2005 at 21:47:52 -0400, Stevan Little wrote: > Hello all. > > In the processing of working with mugwump's shiny new perl6 OO Set.pm. I > realized that we > do not currently have a way to uniquely identify objects in Pugs like the way > we have in > perl5 (object stringification). > > So I asked Autrijus, and he promptly implemented a rudimentary object > numification > scheme, and requested I query the @Larry as to how this should really behave. I think numification and stringification has given us lots of unnecessary pain in p5. Look at all the broken modules which need to be using Tie::RefHash or Set::Object but don't. overload::StrVal($obj) is annoying to type, and annoying to read. It's defensive programming that should have nicer means builtin to the language. Furthermore, reliable, 100% correct (always) behavior should be easier to do than broken behavior that seems OK, so that people don't use it when they aren't future-proofing. Overloading operators are there to allow us to pretend objects really are the things they represent, for equality, printing, and whatnot. This is something else, and does not have to do with the fact that the object is a perl object, a part of the data that the language offers us. This has to do with the meaning we put into the building blocks. I think this should not be a behavior of the data, but something returned from a meta method. I'd like to be able to say $obj.meta.id Or something with a similar meaning, but in a more concise way. Perhaps an operator with ':' in it would be suitable. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me climbs a brick wall with his fingers: neeyah! pgprhsuf3L5Zs.pgp Description: PGP signature
Re: C<::> in rules
On Sat, May 14, 2005 at 01:15:36AM +, Luke Palmer wrote:
: I think the misunderstanding is rather simple. You keep talking like
: you prepend a .*? to the rule we're matching. I think that's wrong
: (and this is where I'm making a design call, so we can dispute on this
: once we're clear that it's this that is being disputed). I think
: there is a special rule:
:
: rule matchanywhere($rx) { .*? <$rx> }
:
: Which makes a *subrule call* to the rule we're matching. Therefore
: ::: just breaks out of that subrule, and backtracks into the .*?
: again.
I want ::: to break out of *that* dynamic scope (or the equivalent
"matchrighthere" scope), but not ::.
Larry
Re: Object Numify/Stringify-ing to Unique values
On Fri, May 13, 2005 at 09:47:52PM -0400, Stevan Little wrote: : Hello all. : : In the processing of working with mugwump's shiny new perl6 OO Set.pm. : I realized that we do not currently have a way to uniquely identify : objects in Pugs like the way we have in perl5 (object stringification). That's what .id is supposed to do, without the bogus numorstringification semantics. It should return something opaque that matches with ~~. On the other hand, the point of =:= is that you can use it without resorting to .id. Basically $a =:= $b should do the same as $a.id ~~ $b.id Perhaps an id has a printable representation if you ask it nicely, but you ought to be able to us an id as a key to an object hash without going through stringiness, for instance. In any event, it should be more like stringification than numification, which is just asking for problems as soon as you get out of a uniform memory model. Larry
Re: Object Numify/Stringify-ing to Unique values
On Fri, May 13, 2005 at 07:28:03PM -0700, Larry Wall wrote: > That's what .id is supposed to do, without the bogus numorstringification > semantics. It should return something opaque that matches with ~~. Okay, implemented as such. What does unboxed values return for their "id", though? 3 =:= 3;# always true? 3.id ~~ 3.id; # ditto? Thanks, /Autrijus/ pgpgb5cAAQDCt.pgp Description: PGP signature
^method ?
Juerd informed me today that .method should still means $_.method. However, for the OO modules we're writing, there still needs to be a way to invoke methods on the current invocant, when the invocant name has been omitted from the method() declaration. Currently Pugs has: $?SELF.method ^method Is any of the two forms considered canonical? Or is there some other alternatives? Thanks, /Autrijus/ pgpw2LZnwdfoK.pgp Description: PGP signature
Re: ^method ?
On Sat, May 14, 2005 at 11:41:23AM +0800, Autrijus Tang wrote: : Juerd informed me today that .method should still means $_.method. : : However, for the OO modules we're writing, there still needs to be a way : to invoke methods on the current invocant, when the invocant name has : been omitted from the method() declaration. : : Currently Pugs has: : : $?SELF.method : ^method : : Is any of the two forms considered canonical? Or is there some other : alternatives? At the moment $?SELF is the only canonical form, though the invocant is also in $_ at least until it's rebound. Any other forms will probably involve a pragma or macro, since there is no consensus on a shortcut. Larry
Re: C<::> in rules
On 5/14/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Sat, May 14, 2005 at 01:15:36AM +, Luke Palmer wrote:
> : I think the misunderstanding is rather simple. You keep talking like
> : you prepend a .*? to the rule we're matching. I think that's wrong
> : (and this is where I'm making a design call, so we can dispute on this
> : once we're clear that it's this that is being disputed). I think
> : there is a special rule:
> :
> : rule matchanywhere($rx) { .*? <$rx> }
> :
> : Which makes a *subrule call* to the rule we're matching. Therefore
> : ::: just breaks out of that subrule, and backtracks into the .*?
> : again.
>
> I want ::: to break out of *that* dynamic scope (or the equivalent
> "matchrighthere" scope), but not ::.
I'm not sure that's such a good idea. When you say:
rule foo() { a* ::: b }
You know precisely where that ::: is going to take you: right out of
the rule. That's the way it works in grammars, and there's no
implicit anything else that you're breaking out of. But you're saying
that when we use a bare // matching a string, that's no longer the
case? In other words, this:
$str ~~ / a* ::: b /
Is different from:
$str ~~ / /
That seems like a pretty obvious indirection, and a mistake to break
it. There's nothing there except , how could it act differently?
Luke
Re: ^method ?
On 5/14/05, Larry Wall <[EMAIL PROTECTED]> wrote: > At the moment $?SELF is the only canonical form, though the invocant > is also in $_ at least until it's rebound. Any other forms will > probably involve a pragma or macro, since there is no consensus on > a shortcut. Er, isn't that a mistake that we don't want to make again? Admittedly it's a fairly small one compared to the other OO mistakes in Perl 5, but it's in the same class. This is one of those TMTOWDTI, TNOWTDI[1] situations. Now, I don't really care if we make the obvious way o.foo, ^foo, \foo/, or whatever, but I think it's important that we pick one. If there's no short way to write it, people will start making them, and every time you pick up a new piece of code, you have to relearn how to say "I". Luke
Re: ^method ?
On 5/14/05, Luke Palmer <[EMAIL PROTECTED]> wrote: > On 5/14/05, Larry Wall <[EMAIL PROTECTED]> wrote: > > At the moment $?SELF is the only canonical form, though the invocant > > is also in $_ at least until it's rebound. Any other forms will > > probably involve a pragma or macro, since there is no consensus on > > a shortcut. > > Er, isn't that a mistake that we don't want to make again? Admittedly > it's a fairly small one compared to the other OO mistakes in Perl 5, > but it's in the same class. This is one of those TMTOWDTI, TNOWTDI[1] > situations. Now, I don't really care if we make the obvious way > o.foo, ^foo, \foo/, or whatever, but I think it's important that we > pick one. If there's no short way to write it, people will start > making them, and every time you pick up a new piece of code, you have > to relearn how to say "I". [1] There's no obvious... Luke
Re: Object Numify/Stringify-ing to Unique values
On Sat, May 14, 2005 at 10:54:34AM +0800, Autrijus Tang wrote: : On Fri, May 13, 2005 at 07:28:03PM -0700, Larry Wall wrote: : > That's what .id is supposed to do, without the bogus numorstringification : > semantics. It should return something opaque that matches with ~~. : : Okay, implemented as such. : : What does unboxed values return for their "id", though? : : 3 =:= 3; # always true? : 3.id ~~ 3.id; # ditto? I think immutable values could work that way, especially if we want to store only a single representation of each immutable string. Basically anything with an id can use that id as its hash key. On the other hand, we don't want to start hashing a boxed immutable value as some different value just because it got transparently boxed up, so we have to be careful about that. And in particular, if hash keys are to work as in Perl 5, we're really taking an immutable snapshot of the mutable string and using that for the key. In essence, whenever you modify a string, you're changing its identity. Larry
Re: ^method ?
On Sat, May 14, 2005 at 04:33:44AM +, Luke Palmer wrote: : On 5/14/05, Luke Palmer <[EMAIL PROTECTED]> wrote: : > On 5/14/05, Larry Wall <[EMAIL PROTECTED]> wrote: : > > At the moment $?SELF is the only canonical form, though the invocant : > > is also in $_ at least until it's rebound. Any other forms will : > > probably involve a pragma or macro, since there is no consensus on : > > a shortcut. : > : > Er, isn't that a mistake that we don't want to make again? Admittedly : > it's a fairly small one compared to the other OO mistakes in Perl 5, : > but it's in the same class. This is one of those TMTOWDTI, TNOWTDI[1] : > situations. Now, I don't really care if we make the obvious way : > o.foo, ^foo, \foo/, or whatever, but I think it's important that we : > pick one. If there's no short way to write it, people will start : > making them, and every time you pick up a new piece of code, you have : > to relearn how to say "I". : : [1] There's no obvious... The obvious way to do it is to declare the invocant. Larry
Re: C<::> in rules
On Sat, May 14, 2005 at 04:26:44AM +, Luke Palmer wrote:
> On 5/14/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> > I want ::: to break out of *that* dynamic scope (or the equivalent
> > "matchrighthere" scope), but not ::.
>
> I'm not sure that's such a good idea. When you say:
>
> rule foo() { a* ::: b }
>
> You know precisely where that ::: is going to take you: right out of
> the rule. [...] But you're saying that when we use a bare //
> matching a string, that's no longer the case? In other words, this:
>
> $str ~~ / a* ::: b /
>
> Is different from:
>
> $str ~~ / /
>
> That seems like a pretty obvious indirection, and a mistake to break
> it. There's nothing there except , how could it act differently?
Because $str ~~ / / puts the ::: in a subrule, whereas
$str ~~ / a* ::: b / does not. It's the same sort of difference
that one gets between
{ return if $a; }
and
sub foo() { return if $a; }
{ foo() }
It's clear that the C in the first case affects control flow in
in the current sub, while the nested C of foo() in the second
case does not.
Pm
