.method == $self.method or $_.method?
There's a discussion going on #perl6/irc.freenode.org right now wondering about what .method means. We'd all assumed it meant $self.method (where $self is always the method invocant) but then had a look at Synopsis 12 which states Dot notation can omit the invocant if it's in $_: .doit(1,2,3) This seems to cripple .method's usefulness by coupling it to $_ which can change often. Now in order to be safe for anything but trivial methods you're back to writing out $self all over the place, something that Perl 6 was supposed to fix about Perl 5. It has also been pointed out that .foo, $.foo, @.foo and %.foo are all (intentionally) similar and all but one operates on the invocant. Only .foo operates on $_. This seems like a newbie trap waiting to happen. MOST of the time .foo will work like $self.foo but every once in a while they'll get caught in a gotcha. Thoughts?
Re: .method == $self.method or $_.method?
I should add that Darren and I, who both have similar tendencies towards
larger scale coding where consistency is far preferred to compactness,
both ended up concluding that our style policies will be to _always_ use
explicit invocants (except of course for one liners).
In the case of the Algorithm::Dependency module that is being ported
over as a test, and given that larger chunks of code have a tendency
towards named iterators in loops anyways, and we've ended up with the
only sane way to be the wordiest of the various ways-to-do-it.
Just for the record, I for one would have much preferred to have .foo be
the same as $.foo and @.foo and %.foo and refer to the invocant method,
at the cost of using C map { $_.foo } .
To describe it in emotional terms, the current situation feels
backwards and inside out.
Adam K
Michael G Schwern wrote:
There's a discussion going on #perl6/irc.freenode.org right now wondering
about what .method means. We'd all assumed it meant $self.method (where
$self is always the method invocant) but then had a look at Synopsis 12
which states
Dot notation can omit the invocant if it's in $_:
.doit(1,2,3)
This seems to cripple .method's usefulness by coupling it to $_ which
can change often. Now in order to be safe for anything but trivial methods
you're back to writing out $self all over the place, something that Perl 6
was supposed to fix about Perl 5.
It has also been pointed out that .foo, $.foo, @.foo and %.foo are all
(intentionally) similar and all but one operates on the invocant. Only
.foo operates on $_. This seems like a newbie trap waiting to happen.
MOST of the time .foo will work like $self.foo but every once in a while
they'll get caught in a gotcha.
Thoughts?
Re: .method == $self.method or $_.method?
That is correct. It probably should have read ...our style policies will be to _always_ use explicit invocants, if .foo ends up meaning $_.foo in the final release (as it does now). (of course, I suspect Darren will keep using them anyways, but then he likes to be even more explicit than I am) :) Personally, .foo meaning $self.foo seems more consistent to my mind, and I'd happily standardise on implicit invocants. The only minor thing I can see would be that you will end up with a slight asymmetry question of if we use $:attribute for a private attribute, do we call :method for a private method? Adam K Michael G Schwern wrote: On Thu, Mar 17, 2005 at 06:04:56PM +1100, Adam Kennedy wrote: I should add that Darren and I, who both have similar tendencies towards larger scale coding where consistency is far preferred to compactness, both ended up concluding that our style policies will be to _always_ use explicit invocants (except of course for one liners). I thought your conclusion was you'd only use an explicit invocant if .foo meant $_.foo. And to drop it if .foo means $self.foo as there's no ambiguity.
Re: .method == $self.method or $_.method?
On Thu, Mar 17, 2005 at 06:04:56PM +1100, Adam Kennedy wrote: I should add that Darren and I, who both have similar tendencies towards larger scale coding where consistency is far preferred to compactness, both ended up concluding that our style policies will be to _always_ use explicit invocants (except of course for one liners). I thought your conclusion was you'd only use an explicit invocant if .foo meant $_.foo. And to drop it if .foo means $self.foo as there's no ambiguity.
Re: s/true/better name/
Larry Wall wrote:
$x = whether $a or $b;
$x = not $a or $b;
would actually be parsed as
$x = whether($a) or $b;
$x = not($a) or $b;
whereas as a native English speaker would probably expect
$x = whether($a or $b);
Reading this makes me wanting:
$x = either $a or $b;
$y = neither $a nor $b;
And of course binary \ and \\ for the latter :)
So I'm thinking we'll just go back to true, both for that reason,
and because it does syntactically block the naughty meaning of true as
a term (as long as we don't default true() to $_), as Luke reminded us.
What is so bad of having a proper type bool? I mean one that gives
a type error or warning for 'answer() == true' if answer returns Int
because bool { not .does Comparable }? This type would be rather
lightweight, compile time only with representation bit. The .bit
property would then actually become a call of 'as bool'.
Regards,
--
TSa (Thomas Sandlaß)
Re: Referencing a caller's slurpy array.
On Wed, Mar 16, 2005 at 11:49:12PM -0600, Rod Adams wrote:
: I haven't gotten a solid answer on when and how Perl will autogenerate
: methods from subs.
In general I don't think of it as autogeneration at all, but as
failover to a different dispatcher. I can't think of a case where an
ordinary sub implies an ordinary method or an ordinary method implies
an ordinary sub. Multi subs can live in both worlds simultaneously
when they're defined within a class, but in that case it's a single
definition that is visible to both dispatchers. There may end up being
some hanky-panky of an autogeneration nature going on to optimize the
more common failover cases, and we've cut ourselves a little slack in
how we handle single argument functions and/or argumentless methods,
but by and large we should just be able to get away with a single
MMD definition for most purposes, and separate definitions where the
valence actually changes.
: For instance, would
:
: @array.grep(/foo/);
:
: generate a call to the list op Cgrep above, or do I need to be
: defining another form of Cgrep that's more agreeable to
: autogeneration? If so, what makes a sub more agreeable to auto method
: generation?
Well, grep is one of those cases where you really need two different
definitions because you have conflicting invocants. If within the
Array class you write a multi sub like this:
multi sub grep (Array @array, Selector $for) {...}
then it can be called either as @array.grep(/foo/) or
grep(@array,/foo/), but never as grep(/foo/,@array).
At least, not unless we install some mechanism like active/passive
voice into Perl, in which case the passive voice could be autogenerated
from the active voice, albeit with a modified verb. But for now
I think two definitions are appropriate, with some thought about
bifurcating the verb into do to and done by variants if there's
likely to be MMD confusion. The .grep variant should probably just
be an ordinary method rather than a squinting multi method to avoid
confusion with the standard listop form.
If we find ourselves with double declarations all over the place, then
maybe we can look for some autogeneration relief.
Larry
Re: .method == $self.method or $_.method?
On Thu, Mar 17, 2005 at 07:00:08PM +1100, Adam Kennedy wrote: : Personally, .foo meaning $self.foo seems more consistent to my mind, and : I'd happily standardise on implicit invocants. I'm thinking about it. There are definitely things to be said for both sides, and maybe we can come up with a solution that's better than what we have. And after all, I originally came up with the .foo notation precisely for the purpose of leaving out $self and still having it self-documenting, as it were. I have a vague feeling that the real linguistic thing going on here is that you shouldn't change the meaning of it within a method, so one possible solution would just be to prohibit any rebinding of $_ to anything other than the current object. In that case we'd have to say that given and for always require - $x inside methods, and that $x is never automatically aliased to $_. But there are other ramifications with switch statements and exception handlers I have to think through, and I'm a slow thinker, and unfortunately I'm having to moonlight at a real job to put bread on the table and pay back all the money I've borrowed over the last several years in order to devote myself to Perl 6--so you'll all just have to be patient with me. Well, you don't have to, but it'd be nice... : The only minor thing I : can see would be that you will end up with a slight asymmetry question : of if we use $:attribute for a private attribute, do we call :method : for a private method? I think those would still be .:method, and we just live with the asymmetry, unless we decide there's sufficient declarational power in the class that we can always distinguish :method from :pairkey, which there might be. But even if there is, most uses of private methods will probably be from within trusted classes, and access to my own attributes through $:foo instead. Plus .:method doesn't require people to remember what's been declared to decide if it's a pair or a private method. Larry
Re: return of copies vs references
Larry Wall writes:
Perl 5 always makes a copy of return values, but that just turns
out to not matter for references, since a copy of a reference is as
good as the original reference. Perl 5 also propagates scalar/list
context into subs. For $:foo it doesn't matter--it always behaves
as a scalar value even in list context. In list context, @:bar and
%:baz should probably return copies of their values much like they
do in Perl 5, (or more likely, some kind of lazy COW reference that
can lazily interpolate into the surrounding lazy list context).
Whether $self.:bar and $self.:baz should behave the same is an
interesting question. They *look* scalar, so maybe they should imply
reference return, and you'd have to say
return $self.:bar[];
return $self.:baz{};
I'll just point out, the rest of this message, with all the autocopy
complexity (according to /some/ people), uses this assumption. It all
happily goes away if $self.:bar returns a list if @:bar is declared.
And I can't, off hand, see any other problems with it. Maybe I'm just
blind, though.
Luke
to get the equivalent of
return @:bar;
return %:baz;
But bare
return $self.:bar;
return $self.:baz;
would be equivalent to:
return \@:bar;
return \%:baz;
But I could argue it the other way too.
: For each, will the calling code be able to
: modify $obj's attributes by modifying the return values, or not?
The caller can modify the value only if an explicit ref is returned (or
the accessor is marked rw).
Where we seem to differ from Perl 5 is that in scalar context, a bare
array or hash automatically enreferences itself rather than returning
some kind of size. So in scalar context, it would seem that
return @:bar;
return %:baz;
and
return $self.:bar;
return $self.:baz;
are equivalent to:
return \@:bar;
return \%:baz;
(Again, $:foo is never a problem unless it's already a reference.)
So the issue is whether this interpretation will encourage people to
accidentally
return references to things they didn't want to give write access to. On the
other hand, making the private methods context sensitive doesn't actually
seem to fix this particular problem, but just pushes it down one level into
the implicit accessor. Maybe we need to work something up where
references returned from read-only accessors are always COW references.
If we assume that [...] is lazy when it can be, then that would be saying that
scalar context forces
return @:bar;
to mean
return [@:bar];
and you'd have to write an explicit
return \@:bar;
to get around that. But that seems kind of hacky and special-casey.
On the other hand, there are going to be strong cultural forces
discouraging people from writing such accessors in the first place,
so maybe we just go ahead and let people return hard refs in scalar
context on the assumption they know what they're doing. I suspect
that most actual accessors to arrays and hashes will just look like
ordinary getter and setter methods with extra args for subscripts, or
will return an explicit proxy if they want to behave like an lvalue.
And in either of those cases, you don't try to return the entire
array or hash. So maybe we should settle for the clean but slightly
dangerous semantics here.
Except that we've defined default read-only accessors that would,
under the clean rules, give people automatic access to arrays and
hashes if called in scalar context. So I think we really only have
three options here for the public accessors:
Don't generate autogenerate accessors at all for arrays and hashes.
Generate array and hash accessors that refuse to work in scalar context.
Generate array and hash accessors that autocopy in scalar context.
Of those three, the last seems the most friendly.
: Going further, what is the exact syntax for each type of attribute to
: specify whether a copy or a reference is returned?
:
: In Perl 5, with the latter two, the difference was a return $bar vs
: return [EMAIL PROTECTED] for reference vs copy. I would like that Perl 6
: is also at least as clearly disambiguated.
If we go dwimmy rather than clean, and assume private array and
hash accessors always return refs, then these return refs from public
accessors:
return \$self.:foo; # in any context
return $self.:bar;# in any context
return $self.:baz;# in any context
return \$:foo;# in any context
return \@:bar;# in any context
return \%:baz;# in any context
and these return copies:
return $self.:foo # in any context
return $self.:bar[]; # in list context
return $self.:baz{}; # in list context
return $:foo; # in any context
return @:bar; # in any context
return
Re: .method == $self.method or $_.method?
Larry Wall writes:
In that case we'd have to say that given and for always require
- $x inside methods, and that $x is never automatically aliased to
$_. But there are other ramifications with switch statements and
exception handlers I have to think through,
In particular, the fact that `map` rebinds $_. Consider:
method data () {
map { .process($_) } @.array;
}
Is that calling `$_.process($_)` for each `$_` in [EMAIL PROTECTED], or is it
calling `$self.process($_)`? It must be the former, which, given the
context, is probably not what was intended (despite the terrible (but
unfortunately, typical) naming, we can still tell what the programmer
was thinking). `.process` means something else everywhere else in the
method, and Perl goes to great lengths to keep it that way, but in this
case it's different.
And it would be a shame to disallow the use of $_ in map.
Disallowing one of the most beautiful areas of Perl, topicalization, in
methods would be irritating at best. Oh, so I can only program in a
crappy subset of Perl because I'm in a method? I don't know about the
other programmers here, but just about all my code is in methods.
Actually, scanning over my most recent module, *all* my code is in
methods, except for the tests.
Luke
Re: return of copies vs references
On Thu, Mar 17, 2005 at 02:06:46AM -0700, Luke Palmer wrote: : I'll just point out, the rest of this message, with all the autocopy : complexity (according to /some/ people), uses this assumption. It all : happily goes away if $self.:bar returns a list if @:bar is declared. : And I can't, off hand, see any other problems with it. Maybe I'm just : blind, though. Yeah, that part's negotiable. But it will seem a little strange if we push it so far that private accessors default to protecting your own data from you, which it would if we forced the autocopy on private accessors in scalar context. I think private accessors will have to be distinguished from public accessors somehow. With forced ref return on private accessors we could be more general in how we specify autocopy on all return statements, but it could be made to work the other way too, in which case we say that only private accessors pay attention to context. And maybe that just falls out of the fact that private accessors are really just subs in disguise. So maybe the distinction is that real methods always return lists, and only subs (and sublike private methods) pay attention to the context in which they're called. That's actually weirdly symmetrical with the notion that only subs can impose compile-time context on their arguments, while methods always have to assume list context because you have to generate the argument list before you can know which method you're going to dispatch to. So I could buy it either way. Opinions? Larry
Re: .method == $self.method or $_.method?
On Thu, Mar 17, 2005 at 07:00:08PM +1100, Adam Kennedy wrote: The only minor thing I can see would be that you will end up with a slight asymmetry question of if we use $:attribute for a private attribute, do we call :method for a private method? That occurs no matter if .method means $self.method or $_.method. Anyhow, I don't see why not. :)
Re: New S29 draft up
Rod Adams skribis 2005-03-16 23:16 (-0600):
Doesn't Czip go until the longest input is exhausted, returning undef
at the end of the shorter ones?
No, as that'd break the most common idiom it introduced: use of an array
with 1..Inf, as in the example you're replying to, but also
for @foos ¥ 1... - $foo, $i { ... }
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
David Storrs [EMAIL PROTECTED] wrote: Aside from links, that's pretty much the entire perlpodtut boiled down into 7 bullets; a little experimentation to get the hang of it and it all holds together nicely, easy to remember. Yes, yes, yes. Pod is one of the things Perl 5 did almost exactly right. It's simple, intuitive, and stays out of your way. It gives you most of the formatting primitives you actually *need*, and nicely balances the need for easy-to-remember and easy-to-type formatting codes with the need to avoid using them on accident. It's a very clean, low-punctuation format, which makes it visually distinctive from the surrounding code. Specifically, I like the use of angle brackets in Pod. Angle brackets are simple, distinctive shapes; they remain wide in variable-width fonts; they're associated with formatting codes in my (HTML-influenced) mind. The most common use of them in Perl 5--method call/dereference--is going away in Perl 6, which makes them even more usable. (I never have a problem correctly marking up C $foo $bar , but occasionally I carelessly type C$foo-bar.) Pod needs incremental improvements--tables, (maybe) footnotes, simpler links, tweaks to =begin/=end, etc. Pod does *not* need to be ripped out and replaced with something very different, especially something that involves adding line noise to documents intended for human consumption. In my mind at least, Pod has five goals: 1. Simple. 2. Adequate. 3. Easy to write. 4. Easy to convert. 5. Readable without a formatter. #5 may be last on the list, but it's not least. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I used to have a life, but I liked mail-reading so much better.
Re: return of copies vs references
Thank you, Luke and Larry, for your replies. They did help.
For now, I will use the syntax $obj.:bar[] and $obj.:baz{} in the
get_bar|baz() accessor methods to get copies returned; if the rules
change again, I'll update later.
I noticed that the example seemed incomplete, saying only what would
happen with the above in list context, and not saying what would
happen in scalar context.
I would like a way of specifying that the copy always happens
regardless of the caller's context. This doesn't have to be a
language 'default', and I'm fine if its a little more verbose, just
as long as its consistent and unambiguous.
return $self.:foo # in any context
return $self.:bar[];# in list context
return $self.:baz{};# in list context
return $:foo; # in any context
return @:bar; # in any context
return %:baz; # in any context
Eg, something that is like lines 5 and 6, but lets me explicitly use 'self'.
-- Darren Duncan
retiring wantarray?
Hola...
This message is not about removing wantarray, but finding a better
solution for a typical but annoying usage-idiom.
sub value_added { # not really a wrapper
my $result = original(@args);
...
return $result;
}
Is a typically broken subroutine in perl 5, unless original() never
returns lists. Usually people use wantarray, or if they're being
even more politically correct, they use Want, but this is an
annoying overhead.
What are perl6's solutions towards making this easier? I tend to
design around this, normally returning lists, unless the sub name
implies singularity.
Here are some ideas:
# i don't like this one, it complicates things
sub value_added {
original(@args); # return is collected here
} after { # but just before leaving, this is done:
... # how do we access the return? what can you do here?
}
# this seems nicer, but very ad-hoc
sub value_added {
return_later(original(@argS);
...
# with no explicit return or return later, the return_later is
# returned, instead of the last expression's result
}
# this is my favourite
sub value_added {
$return is context_sensitive = original(@args); # hides wantarray magic
... # you can ask $return what it's context is
# but it pretends to be just a normal value anyway (array ref in
# list, etc). How do you modify it, without breaking it?
# implicit strong type?
$return; # magically unwraps
}
# or in perl5, maybe it could be done like:
sub value_added {
my $return = Returner::Smart-new(sub { original(@args) });
# Returner is an object that does Want based lookups
...
$returner-return; # could this do lvalue crap?
}
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me does a karate-chop-flip: neeyah!!
pgpi8tV5KTNDl.pgp
Description: PGP signature
Re: retiring wantarray?
BTW, i should mention that given want { } in s06 is nice for
replacing the simple kind of wantarray usage cases, but not what
this message brought up.
In short, i did read it, so don't send me links ;-)
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me whallops greyface with a fnord: neeyah!!!
pgpH6GwU4Nyq1.pgp
Description: PGP signature
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Thu, 2005-03-17 at 02:17 -0800, Brent 'Dax' Royal-Gordon wrote: David Storrs [EMAIL PROTECTED] wrote: Aside from links, that's pretty much the entire perlpodtut boiled down into 7 bullets; a little experimentation to get the hang of it and it all holds together nicely, easy to remember. Yes, yes, yes. Pod is one of the things Perl 5 did almost exactly right. Absolutely, and that's why I'd like to see more POD details preserved. It's simple, intuitive, and stays out of your way. It gives you most of the formatting primitives you actually *need*, and nicely balances the need for easy-to-remember and easy-to-type formatting codes with the need to avoid using them on accident. It's a very clean, low-punctuation format, which makes it visually distinctive from the surrounding code. This is the spirit in which I've absorbed some of Kwid into my proposal only where it supports those goals. I've removed some extra formatting characters because I thought that they added too many chances for overlap with real documentation. I've also searched my local PODs to see where AJS Kwid would overlap POD and cause problems (6.4% of my local PODs, for example, start some lines with *, which would be a minor, but notable problem, but 13.1% start a line with - which is a larger problem, thus my *1 which could easily be *- if we prefer that). Specifically, I like the use of angle brackets in Pod. Angle brackets are simple, distinctive shapes; they remain wide in variable-width This is aesthetic preference. I could cite the reasons that I have an aesthetic preference for the other syntax, but the reality is that angle brackets aren't angle brackets; they are less-than (Elt) and greater- than signs (Egt). We ignore this fact at our peril, and the hacks in pod syntax (e.g. C ) to get around this are glaring anti- huffmanisms. The most common use of them in Perl 5--method call/dereference--is going away in Perl 6 Hmm, I remain unconvinced of that as the most common use, especially with the copious use of =. Still, in my local source tree you're right, though by a factor of 2. Perl 6 also adds new uses of Egt and Elt for pipelining, and further expands the usefulness of the = operator as a pair constructor. Rules also add new uses of these characters, but those are balanced, so improving POD with a real grammar specification would solve for that. Pod needs incremental improvements--tables Oops, forgot that one. I'll add it tonight, when I get home from work. (maybe) footnotes Good point, and I'd add that to X[...] rather than introducing something new, personally. simpler links, tweaks to =begin/=end, etc. I think everything you list above is EXACTLY AJS Kwid, with one exception, which is the dreaded paradigm shift of using [] instead of Much as it may be an EMOTIONAL sticking point, it's a very minor thing. If we can agree on everything else, and I suspect we can, then let's come back to that. Pod does *not* need to be ripped out and replaced with something very different, yes, yes, yes! especially something that involves adding line noise to documents intended for human consumption. yes, yes, yes! Thanks Brent, I'm not sure if you intended your mail as an endorsement, but other than one sticking point, you and I appear to be on the same page. Thank you for your message.
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Wed, 2005-03-16 at 15:09 -0800, David Storrs wrote:
C[$x[0] $y] # hmmm...parser ok with that?
C[$x[0] $] # hmmm...error, but what was intended: $y] or $]]?
In the former case, it's fine. See the grammar I sent last night.
In the latter case, you would get balanced-[] matching, and given how
hard it is for PERL to do the right thing, there, I think it's fair to
fall back on only perl can parse perl, and just do what the eye
suggests is correct. Remember that POD (and thus Kwid) are not intended
to be Perl-specific, just Perl-friendly. You can always:
C{$x[0] $]}
If you need unbalanced []s
That said, I'd be ok with something like Z[name|text] and Z{name|...}
for doing external grammars, but it'd still have to live inside one of
the balanced operators correctly.
Please also note that as a side-effect of using extract_bracketed in my
grammar,
C[\]]
works. This introduces escaping which may or may not be good. It was not
a conscious decision, just a side-effect. I PREFER:
C{]}
Which also works.
C $x[0] $y # parser's ok (so's the human)
C $x[0] $# oh, obviously $y was intended
By the same token:
C[ $x[0] $y ] # Parser's ok
C[ $x[0] $ ] # Parser's ok... human might care
the massive savings in terms of taking
advantage of the legions of people who are learning Wiki syntax these
days. Making POD *more* Wiki-like without sacrificing useful features of
POD is invaluable in terms of tech writers and other
non-Perl-programmers writing useful docs in POD!
Here's the real crux of your argument, and the real crux of my problem
with this approach. I don't like Wiki syntax; to me, it seems
arbitrary and non-unified.
Agreed.
I use Wikis, I run one, I recognize their usefulness. I just don't like
them.
Fair enough. I don't like them either, for many reasons. I like them in
equal measure. It's a bit like sendmail ;-)
Here are some of the formatting rules for TWiki (the Wiki version I
use):
1) Elements of a bulleted list must match /^ {3}\* /
2) Elements of a numbered list must match /^ {3}1 /
3) Headings must match /^*\++/. Number of +s determines level
4) *bold*
5) /italic/
6) =fixed font=
7) verbatim put text to be rendered as-is here /verbatim
What is the organizing priciple? What similarities do they have?
Yes, yes, yes. I agree. See AJS Kwid. Please.
Contrast this to POD (I'm not trying for point-to-point equivalence):
1) All formatting starts with = in the first column.
Add ONE new item to that list: *
2) Every POD command must have a blank line above and below it.
Why do you want TWO ways of determining commands? I can see requiring a
blank line above OR below, just for readability, but not both. I'm a POD
lover. I've used POD since the mid-90s and I'm THRILLED with it.
However, there's that nagging problem with having to type:
\n\n=head1 Foo\n\n=head2 Introduction\n\nTopics:\n\n=over 5\n
\n=item *\n\nFoo vs. Bar\n\n=item *\n\nC\n\n
AJS Kwid:
\n= Foo\n\n== Introduction\n\nTopics:\n* Foo vs Bar\n* C[\n]\n
3) A list of any type starts with =over N and finishes with =back
Again, you're asking for a second way to determine what point 1 already
told you. If this were code, I might buy that, but it's documentation.
We like documentation. We want to encourage documentation and =over
ain't the way to encourage nothing ;-)
If you prefer a requirement for a leading blank line for readability, I
could see that, and we could talk about it. I do see the value in
=begin list/=end list, but only in cases like this:
=begin list
* a
* b
=end list
=begin list
* Apples
* Grapes
=end list
Where you wish to make it clear that you are ending the first list.
Which do you find more readable:
=over 5
=item C--help
Help is given
=item C--verbose
Verbosity is given
=item C--debug
Debugging is done
=back
vs:
=begin list
*= C[--help]
Help is given
*= C[--verbose]
Verbosity is given
*= C[--debug]
Debugging is done
=end list
Replace *= with + and =begin list with .list and =end list with .list.
for the original Kwid proposal.
4) List items are denoted with =item X where X is either * (bullets),
an int (numbered), or word/phrase. Use only one type per list.
5) Headings are denoted by =head1, =head2, etc
6) Formatting effects are done with Xtext where X is one of:
B (bold), C (code), I (italics). You may also use
X text or X text if you have or in your text.
7) Text that is indented will be rendered as-is in fixed width font.
There's a 1:1 mapping with all of the above except for the vs []/{}
and =head1 heading vs = heading, which are simply syntactic
transformations. If you want =head1, then you can add a pre-processor,
or we
RE: .method == $self.method or $_.method?
Autrijus Tang wrote:
Luke Palmer wrote:
And it would be a shame to disallow the use of $_ in map.
Err, wait, I don't think we are discussing whether $_ is to
be outlawed in map {}.
Perhaps we should consider making $_ readonly in map and grep?
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com garrett at scriptpro dot com
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
Aaron Sherman skribis 2005-03-17 8:30 (-0500): This is aesthetic preference. I could cite the reasons that I have an aesthetic preference for the other syntax, but the reality is that angle brackets aren't angle brackets; they are less-than (Elt) and greater- than signs (Egt). We ignore this fact at our peril, and the hacks in pod syntax (e.g. C ) to get around this are glaring anti- huffmanisms. Other than awareness, this really doesn't have a point to it. In ASCII, ' was meant as an apostrophe, but we use it as a quote. Yen was never meant to have anything to do with zipping. Guillemets originally had nothing to do with parallelization. The hacks for square brackets are exactly the same. Think of how [EMAIL PROTECTED] would be parsed without nesting. And if you say nesting fixes all, then consider C[]] as a counter-example. Are you willing to parse code in a simple documentation format? Pod needs incremental improvements--tables Oops, forgot that one. I'll add it tonight, when I get home from work. See PodTables in the Pugs wiki. Pod does *not* need to be ripped out and replaced with something very different, yes, yes, yes! Agreed. especially something that involves adding line noise to documents intended for human consumption. yes, yes, yes! Agreed, though I like *bold*, /italic/, _underline_ and `code` very much. I'd like an option to enable it. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: .method == $self.method or $_.method?
Garrett Goebel skribis 2005-03-17 8:37 (-0600): Perhaps we should consider making $_ readonly in map and grep? That's one way to avoid clever tricks. Please let's not. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: .method == $self.method or $_.method?
I've been thinking about this in my sleep, and at the moment I think I'd rather keep .foo meaning $_.foo, but break the automatic binding of the invocant to $_. Instead of that, I'd like to see a really, really short alias for $self. Suppose we pick o for that, short for object. Then we get self calls of the form: o.frobme(...) Now that has some interesting possibilities for variants. We could have c.bless(...) which would presumably give you the class of the invocant. Perhaps more interestingly, if o and c are functions, then you can provide arguments, with a default of 0. So the above could really be short for o(0).frobme(...) c(0).bless(...) Now, we also have this other problem that we're forcing people to name all the invocants for MMD methods, poor things. But with the above notation, the first invocant is o(0), the second invocant is o(1), etc. Not that we would encourage people to code this way, but it'd be nice to have a way of getting at the actual args in the same way we used to always get at them using @_. (Such a notation might well be useful in wrappers that don't know what they're being wrapped around, such as various debugging wrappers.) That's what Sleepy Brain says. But Coffee Brain despises Sleepy Brain. :-) Larry
Re: .method == $self.method or $_.method?
On Thu, 17 Mar 2005, Larry Wall wrote: really short alias for $self. Suppose we pick o for that, short for object. Then we get self calls of the form: o.frobme(...) How 'bout ..frobme(...)? Or would it be a hell to tell from C..? (Mnemonic reminder: '.'=myself, '..'=my mom - poor analogy, actually!) How 'bout a single underscore? _.frobme()?!? Michele -- L'amava come si ama qualcosa che e' necessario alla vita. La odiava come si odia chi tradisce. - Laura Mancinelli, Gli occhi dell'imperatore
Re: .method == $self.method or $_.method?
On Thu, Mar 17, 2005 at 08:41:26AM -0800, Larry Wall wrote: : Then we get self calls of the form: : : o.frobme(...) Sleep Brain would also like to point out that this lets you use o standalone when you want to pass the current object as an ordinary argument to some other class. Likewise for c, if we decide to have that too. Coffee Brain perks up and points out that for strategic psychological reasons it really likes the fact that, Huffmanly speaking, the dynamic class can be as short as c and the static class as long as $?CLASS. Larry
Re: .method == $self.method or $_.method?
On Thu, Mar 17, 2005 at 05:52:15PM +0100, Michele Dondi wrote: : On Thu, 17 Mar 2005, Larry Wall wrote: : : really short alias for $self. Suppose we pick o for that, short : for object. Then we get self calls of the form: : :o.frobme(...) : : How 'bout ..frobme(...)? Or would it be a hell to tell from C..? : (Mnemonic reminder: '.'=myself, '..'=my mom - poor analogy, actually!) : : How 'bout a single underscore? _.frobme()?!? Thought about those in the night, but they don't strike me as visually distinct enough. They just look like someone stepped on the front of your expression. Larry
Re: New S29 draft up
On Thu, Mar 17, 2005 at 11:02:47AM +0100, Juerd wrote:
: Rod Adams skribis 2005-03-16 23:16 (-0600):
: Doesn't Czip go until the longest input is exhausted, returning undef
: at the end of the shorter ones?
That's what has been specified.
: No, as that'd break the most common idiom it introduced: use of an array
: with 1..Inf, as in the example you're replying to, but also
:
: for @foos ¥ 1... - $foo, $i { ... }
Maybe we need a short-circuit zip:
for @foos ¥¥ 1... - $foo, $i { ... }
Larry
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On 17/03/05 00:49 -0500, Aaron Sherman wrote: On Wed, 2005-03-16 at 13:42 -0800, Brian Ingerson wrote: Well, look over AJS Kwid, and see what you think. The bullet syntax you give could work fine as a replacement for what I demonstrate, but I think everything else is pretty much 1:1. Now it's just a matter of: do you make it Wikiish or PODish? Aaron, I think AJS Kwid is fine if it fits your brain. It doesn't fit mine in much the same way that Kwid doesn't fit yours, in much the same way that Pod doesn't quite fit either of ours. The interesting thing to me is that all 3 syntaxes map over the same data model and thus are easily interchangable. The other interesting thing is that all three could be supported without affecting the Perl5 or Perl6 syntax proper. Sam mugwump Vilain refers to each of these syntaxes as /Pod dialects/. He is working on more formally defining the common model or AST that these dialects map to. Given that, I am going to continue working on the Kwid dialect and developing the Kwid tools I have started. The ideas in AJS Kwid seem too different to incorporate without muddying the Kwid vision. I encourage you work on the AJS Kwid dialect too. I would guess that the Kwid tools I'm working on, when completed, could be easily adapted to AJS Kwid. Cheers, Brian PS All my work thus far is available in the pugs repository.
Re: .method == $self.method or $_.method?
On Thu, Mar 17, 2005 at 08:41:26AM -0800, Larry Wall wrote: I've been thinking about this in my sleep, and at the moment I think I'd rather keep .foo meaning $_.foo, but break the automatic binding of the invocant to $_. Instead of that, I'd like to see a really, really short alias for $self. Suppose we pick o for that, short for object. Then we get self calls of the form: o.frobme(...) Now that has some interesting possibilities for variants. We could have c.bless(...) Wow. With those single-casting-cost cantrips, the OO color will surely make a huge comeback in Perl6: The Gathering golfing tournaments! :) I like them. They look really really good to my eyes after the first 20 minutes or so of mental reconfiguration. For some strange psychological reasons, they make Pugs 6.2 so much more enjoyable to work on for me. :-) Thanks, /Autrijus/ pgpuLiyu2UtLd.pgp Description: PGP signature
Re: return of copies vs references
Larry Wall wrote:
That's actually weirdly symmetrical with the notion that only subs can
impose compile-time context on their arguments, while methods always
have to assume list context because you have to generate the argument
list before you can know which method you're going to dispatch to.
Sorry if it's only me, but I don't understand what this means.
I get, that at the call site of a sub, first of all the lexically
closest sub can be determined at compile time. This means its signature
is available and can be checked and imposed on the arguments---right so far?
Single invocant methods are defined inside classes. Thus the knowledge of
the compiler about their signature hinges on how well the type of the invocant
can be determined. If the data is insufficient this is---depending on compile
mode---either a static type error or dynamic lookup has to be compiled,
with an optional warning.
BTW, do method names have to be pre-declared? Or does the following just
defer the existence check:
sub blubb ( $obj )
{
print $obj.somemethod( FirstArg, SecondArg );
}
What I want to ask is: is .somemethod() parsed purely syntactically?
And is there a compiler mode where this is a type error like type Any
doesn't have .somemethodStr,Str?
With multi subs and methods I guess a lexical definition is needed as for
subs. But that doesn't mean that all dispatch targets are known already.
Thus a dynamic built-up of the arglist and MMD is compiled. Right?
A very nice feature of the compiler here were to perform implementation
side checks when the complete program is loaded? This involves potential
ambiguity and absence failures.
BTW, how far down to pure byte code can Perl6 packages be compiled?
Too much off the mark?
--
TSa (Thomas Sandlaß)
Re: New S29 draft up
Larry Wall wrote:
On Thu, Mar 17, 2005 at 11:02:47AM +0100, Juerd wrote:
: No, as that'd break the most common idiom it introduced: use of an array
: with 1..Inf, as in the example you're replying to, but also
:
: for @foos ¥ 1... - $foo, $i { ... }
Maybe we need a short-circuit zip:
for @foos ¥¥ 1... - $foo, $i { ... }
Or maybe that idiom should be written as:
for @foos.kv - $i, $foo { ... }
But that gets a bit shaky beyond the shortest case. For instance,
there's no easy way to simulate:
for 1... ¥ @foos ¥ @bars {...}
So I'll add a CBit +$shortest to Czip, and leave it up to you to
determine what the operator form of it should be, if any.
for zip :shortest 1...; @foos; @bars {...}
-- Rod Adams
Re: .method == $self.method or $_.method?
On Thu, 17 Mar 2005, Larry Wall wrote:
:o.frobme(...)
:
: How 'bout ..frobme(...)? Or would it be a hell to tell from C..?
: (Mnemonic reminder: '.'=myself, '..'=my mom - poor analogy, actually!)
:
: How 'bout a single underscore? _.frobme()?!?
Thought about those in the night, but they don't strike me as visually
distinct enough. They just look like someone stepped on the front
of your expression.
But then do 'c' and 'o'? They're too identifier-like IMHO to be
psychologically associated with something 'special'. It kind of reminds me
of some fortran code I saw (I don't know fortran) and I could hardly cope
with those 'c'omments...
(However I would be favourable to {one,two} letter(s) long builtin
functions/operators, when they are frequently used (think huffmanization)
and talking about language design in general.
Michele
--
Your right, I didn't think of that at all, but still, who's gonna go into
the temp internet folder and create a cookie? At least not most users.
Of course *most* users aren't going to do that. *Most* users aren't
trying to hack your site! You don't program securely for *most* users -
you program securely for the few users who *are* trying to be malevolent.
- Paul Lalli in clpmisc, Re: free source authentication script
Re: New S29 draft up
Larry Wall skribis 2005-03-17 9:05 (-0800):
That's what has been specified.
Maybe we need a short-circuit zip:
for @foos ¥¥ 1... - $foo, $i { ... }
Because ¥ is shorter than ¥¥, and because the 1... thing is probably
going to be used much, I think it should be the one that returns the
shorter list.
my @foo = 1..3;
my @bar = 1..5;
@foo ¥ @bar # = 1 1 2 2 3 3
@foo ¥¥ @bar # = 1 1 2 2 3 3 undef 4 undef 5
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: s/true/better name/
John Macdonald wrote: A shotgun brainstorming of possible operator names: well, I didn't follow this thread very closely (and I don't know if it is officially closed :-) but I suddenly thought about yes. what about: $x = not $a or $b; # vs $x = yes $a or $b; $yesno = yes any(@foo) == any(@bar); may not be gramatically correct English, but isn't it intuitive enough? cheers, Aldo
Re: s/true/better name/
On 17/03/05 04:40 +0800, Autrijus Tang wrote: On Wed, Mar 16, 2005 at 12:09:40PM -0800, Larry Wall wrote: whereas as a native English speaker would probably expect $x = whether($a or $b); So I'm thinking we'll just go back to true, both for that reason, and because it does syntactically block the naughty meaning of true as a term (as long as we don't default true() to $_), as Luke reminded us. But true() reads weird, and it does not read like an unary (or list) operator at all to me. As the bikeshedding is still going on, may I suggest aye()? It is the same length as not(), both are adverbs, and is rare enough to not conflict with user-defined subs. 'Tis a pity nobody suggested `tis()`. Cheers, Brian
Re: s/true/better name/
Mark J. Reed writes:
Luke Palmer wrote:
Marcus Adair writes:
Additionally I question whether this is truly a case improving to the
point of least surprise? After all, I don't know a programmer who's
going to be surprised by what true means. There are still *some* things
you may have to learn in software dev 101 ;)
The problem is this (common) one:
if answer() == true {
# do something
}
We want to give the programmer no good way to do that, because it's
wrong.
What do you mean wrong? It looks perfectly valid to me. It's
redundant, since answer() by itself would suffice as a condition with no
comparison, but does that make it wrong?
It's wrong in the same way that:
if (ref $obj eq 'MyClass') {...}
Is wrong. If answer() decides that it should start returning a more
interesting value of true, then the test fails.
Luke
Re: s/true/better name/
On Thu, Mar 17, 2005 at 14:09:26 -0700, Luke Palmer wrote: Is wrong. If answer() decides that it should start returning a more interesting value of true, then the test fails. I think the only name for this function, from which you can actually understand what it does, is bool(?:ean)? as a context enforcer. It's got the following properties: - well known and accepted semantic meaning - no associated action (it doesn't do anything) - relatives (scalar, list, hash) - it maps to '?', which is also the prefix to certain operations, thus unambiguating further As I see it 'so', 'whether', 'true', 'is', 'id', etc all have too much english cargo, or are not exactly what it does. The only one that I can see fitting here, as an action instead of a context disambiguation is 'istrue', which takes an expr, and returns a bool if expr is true. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me sneaks up from another MIME part: neeyah! pgpRod53H02RA.pgp Description: PGP signature
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Thu, 2005-03-17 at 09:54, Juerd wrote: Pod needs incremental improvements--tables Oops, forgot that one. I'll add it tonight, when I get home from work. See PodTables in the Pugs wiki. Or see the archive of this list, where we hammered it out previously. YMMV. I'll have the second revision available sometime tonight, I think, hopefully with an AJS Kwid to KwidData to POD translator (lossy, but still mostly workable). -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
Aaron Sherman skribis 2005-03-17 16:30 (-0500): See PodTables in the Pugs wiki. Or see the archive of this list, where we hammered it out previously. Since when is anything in Perl 6, except its name, set in stone? PodTables is a more detailed and more consistent approach to a suggestion I did long time ago. It also states what I found important when inventing the syntax: things to consider when inventing your own syntax for the same feature. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: .method == $self.method or $_.method?
I think this should mean $_, and if the user really really really
wants to do .foo on the invocant, then why not just say:
method bar ($_:) {
.foo;
}
This keeps $_ unambiguosly the 'it', while 'this' is more specific.
Think:
it puts the lotion on the skin
method blah {
for ($.prisoners) {
.put($lotion, $skin); # is the same as
$_.put($lotion, $skin);
}
}
It is not us, it is not self, it is not here, it is, err, just the
default. For implies it in this case.
Contrary:
this puts the lotion on the skin
self ~~
method cooperate ($self:) { # in class Prisoner
# this method puts lotion on skin, haha
$self.put($lotion, $skin);
}
We are discussing a certain thing, which is the invocant. It's not
default. The default might be something else altogether. It's pretty
obvious that in a method like this the invocant is the default, but
what if it isn't?
Perhaps i'm sort of forcing this distinction.
However, I wouldn't be too happy with having to do this, though:
method data {
map { $OUTER::_.process($_) } .things;
}
or having to name the invocant every time I want to map {}.
Lastly, what is wrong with
$.method?
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me dodges cabbages like macalypse log N: neeyah!
pgpqRpkMb5Me5.pgp
Description: PGP signature
Re: s/true/better name/
Brian Ingerson skribis 2005-03-17 11:57 (-0800):
'Tis a pity nobody suggested `tis()`.
That sounds more like a smart match on the topic:
if tis 'foo' { ... }
if $_ ~~ 'foo' { ... }
't = $_,
is = ~~
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Thu, 2005-03-17 at 16:39, Juerd wrote: Aaron Sherman skribis 2005-03-17 16:30 (-0500): See PodTables in the Pugs wiki. Or see the archive of this list, where we hammered it out previously. Since when is anything in Perl 6, except its name, set in stone? PodTables is a more detailed and more consistent approach to a suggestion I did long time ago. I think you're thinking of something else. I'm talking about Luke's proposal from this very list, back in Aug, which was a followup on Larry's comments about my proposal, and which I agreed was far better than what I had suggested in the first place. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Thu, 2005-03-17 at 12:28, Brian Ingerson wrote: The interesting thing to me is that all 3 syntaxes map over the same data model and thus are easily interchangable. The other interesting thing is that all three could be supported without affecting the Perl5 or Perl6 syntax proper. If any of the above was news to you, then I suggest you take another look at why POD (and more generally, any abstract markup language) exists. If any of the above were NOT true, it would be contrary to the entire point of an abstract, layout-neutral markup language. It is, however, contrary to the spirit of POD for you or me to continue much further down this road (see below). Sam mugwump Vilain refers to each of these syntaxes as /Pod dialects/. He is working on more formally defining the common model or AST that these dialects map to. Why? Seriously, why on earth do you want to encourage the proliferation of variant markup languages?! There aren't enough? My effort here was to try to PREVENT the proliferation (e.g. by Kwid and POD butting heads and ending up in a stalemate). The only problem is that, presented with a compromise, the Kwid folks seem to be content to ADD it to the list of variants rather than, in fact, compromise and collapse the list. I'll continue only as far as is needed to propose this in full as an example parser / converter, and then I'm going to stop. My goal is not to proliferate the number of markups further, and I'd MUCH rather see Perl 6 rely on POD than fragment the SINGLE MOST IMPORTANT TASK in creating code to share with the world: documentation. If I'm left on a desert island with POD, then the only part I'll lament is the desert island. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
Aaron Sherman [EMAIL PROTECTED] wrote: Specifically, I like the use of angle brackets in Pod. Angle brackets are simple, distinctive shapes; they remain wide in variable-width This is aesthetic preference. I could cite the reasons that I have an aesthetic preference for the other syntax, but the reality is that angle brackets aren't angle brackets; they are less-than (Elt) and greater- than signs (Egt). We ignore this fact at our peril, Only in name. Years of HTML and Perl have trained me to treat these as bracketing constructs, and Perl 6 is set to increase that use. and the hacks in pod syntax (e.g. C ) to get around this are glaring anti- huffmanisms. Whatever bracketing character we decide to use, there will always be occasions where we need to use it in an unbalanced way within a formatting code. (Though I do admit that angle brackets are more likely to be unbalanced than other characters.) The problem I have with square brackets specifically is that they get lost really easily, especially in variable-width fonts. Gmail, for example, displays e-mail in a sans-serif font, and virtually all such fonts have narrow square brackets. The square brackets in your examples were visually lost in the surrounding text--without spaces, square brackets are invisible. That's okay when you're subscripting, because your brain doesn't really need them to understand what's going on, but it's not when you're applying and reading formatting codes. Further, although Perl 6 is the time to make such a change, I'm not convinced the change is really necessary. We might be able to avoid a few uses of C , but is that a big enough win to change *yet another* aspect of Perl? Especially an aspect programmers can--and traditionally did--ignore? The most common use of them in Perl 5--method call/dereference--is going away in Perl 6 Hmm, I remain unconvinced of that as the most common use, especially with the copious use of =. Still, in my local source tree you're right, though by a factor of 2. Are you looking at your entire source tree, or just the Pod in it? The code in Pod--and especially the short snippets of code typically included in a C construct--is very different from arbitrary Perl code. Perl 6 also adds new uses of Egt and Elt for pipelining, and further expands the usefulness of the = operator as a pair constructor. Rules also add new uses of these characters, but those are balanced, so improving POD with a real grammar specification would solve for that. I definitely support intelligently defining the way Pod handles angle brackets which aren't part of a formatting code. I also think writing a reference grammar would be an excellent idea. Thanks Brent, I'm not sure if you intended your mail as an endorsement, but other than one sticking point, you and I appear to be on the same page. Thank you for your message. I intended my e-mail to be an endorsement of Pod as it exists, with extensions rather than a redesign. I think you have mostly the right idea, but I really don't think switching to square brackets is necessary. By the way, I think I've seen a few people suggest some sort of syntax-switching mechanism for Pod6. The day people have to think about what dialect of Pod they're using is the day Pod dies as a useful documentation language. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I used to have a life, but I liked mail-reading so much better.
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Thu, 2005-03-17 at 17:07, Brent 'Dax' Royal-Gordon wrote:
Aaron Sherman [EMAIL PROTECTED] wrote:
and the hacks in
pod syntax (e.g. C ) to get around this are glaring anti-
huffmanisms.
Whatever bracketing character we decide to use, there will always be
occasions where we need to use it in an unbalanced way within a
formatting code.
Absolutely yes. See C[...] vs C{...} vs C[\]]
I'm pointing out that the ROUTINE case is to need and in unbalanced
ways. Hence we have names for them that to not involve the words open,
close, left or right. We could name [, fobit, but then people
would automatically call ] a right-fobit or a close-fobit. We look
at a piece of code or documentation that contains an un-balanced fobit
and we get a little chill because it's WRONG somehow. THAT is the kind
of balanced operator you want to tie your documentation to.
The most common use of them in Perl 5--method call/dereference--is
going away in Perl 6
Hmm, I remain unconvinced of that as the most common use, especially
with the copious use of =. Still, in my local source tree you're right,
though by a factor of 2.
Are you looking at your entire source tree, or just the Pod in it?
The code in Pod--and especially the short snippets of code typically
included in a C construct--is very different from arbitrary Perl
code.
I EXPLICITLY ignored POD. I don't have the find+perl that I used handy
any more, but I was counting state every time I saw an ^=[hoib] and
decrementing state every time I saw an ^=cut so that I only counted
code... I probably caught some strange gunk after __END__ and __DATA__
tags, but not enough to throw the stats that far off.
It was 23k vs. 44k.
Perl 6 also adds new uses of Egt and Elt for pipelining, and further
expands the usefulness of the = operator as a pair constructor. Rules
also add new uses of these characters, but those are balanced, so
improving POD with a real grammar specification would solve for that.
I definitely support intelligently defining the way Pod handles angle
brackets which aren't part of a formatting code. I also think writing
a reference grammar would be an excellent idea.
Already done, see my previous message. It's still brain-dead in some
places, and I need to re-work it to correctly handle nested operations
(e.g. B[I[...]]), but I'll have that soon. It will also, I've decided,
parse POD. Just as Perl 6 parses Perl 5 by recognizing the first few
statements, AJS Kwid will recognize =head.* as an indication that POD
is being used, and parse it into KwidData internally so that the same
tools could be used.
I'm stopping once it works. I'm not looking to fork POD. If people don't
like the proposal, once they can play around with it, then I'll drop it.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
Aaron Sherman wrote: Sam mugwump Vilain refers to each of these syntaxes as /Pod dialects/. He is working on more formally defining the common model or AST that these dialects map to. Why? Seriously, why on earth do you want to encourage the proliferation of variant markup languages?! There aren't enough? My effort here was to try to PREVENT the proliferation (e.g. by Kwid and POD butting heads and ending up in a stalemate). The only problem is that, presented with a compromise, the Kwid folks seem to be content to ADD it to the list of variants rather than, in fact, compromise and collapse the list. I'll continue only as far as is needed to propose this in full as an example parser / converter, and then I'm going to stop. My goal is not to proliferate the number of markups further, and I'd MUCH rather see Perl 6 rely on POD than fragment the SINGLE MOST IMPORTANT TASK in creating code to share with the world: documentation. Well, I don't think anyone wants to see as many POD dialects as there are wiki text formats (BBCode, anyone?). Maybe there will be something very close to the original POD, but with a verbose way of making tables, and an enhanced linking syntax. But otherwise identical to the original Perl 5 POD. Note that POD dialects, and differing POD conventions already exist in Perl 5 and are in common use. They were designed in the original POD with the =for tag. At the moment, tools like `pod2html' have to be heavily aware of the POD dialect, which I think is sub-optimal when it comes to some of the really interesting things people have achieved with POD. Look at MarkOv's OODoc, or Test::Inline, for instance. All I'm trying to do is giving these beasts a name, and defining a mechanism by which they can be used by tools that only know how to deal with standard documents - thus giving users the freedom to define a local convention if one of them doesn't quite fit their needs. Using a local Subversion repository, and Request Tracker, and want to be able to put hyperlinks in POD to refer to these entities? No problem, just extend the dialect and add a link style. Then select from a dozen output tools or variants to see which one works for you. Sam.
Re: New S29 draft up
On Wed, 2005-03-16 at 03:18, Rod Adams wrote:
I just posted a fresh copy of S29 to:
http://www.rodadams.net/Perl/S29.pod
http://www.rodadams.net/Perl/S29.html
From there:
=head2 Obsolete
=item chop
Chop removes the last character from a string. Is that no longer useful,
or has chomp simply replaced its most common usage?
chomp($x)
vs
substr($x,-1) = '';
Hrm... well, I guess it's not SO bad
=item dbmopen, dbmclose
YAY! ;)
=item dump
With Parrot?
Yes, but it won't be the same, and it should probably come from a
module. I'm sure that's going to be required by several folks from
several different areas (e.g. for checkpointing and all of the uses that
come from that like process migration). It will also be 99% Parrot's
job.
=item srand
Crand(:seed($x))
Ah, no. Crand(:seed($x)) will invoke rand, will it not? That's not
what srand does. srand puts you in a known state, and leaves you there.
Without srand, even if you're using the same PRNG, you can't plug in
someone else's seed, and then call the function that will use it, unless
you can rewind/unshift the PRNG.
That said, I'd very much like Perl 6 to provide (either through Parrot
or on its own) a default strong, non-blocking random number generator
out of the box (though ALSO a rand that's just a PRNG which does not
exhaust the system's entropy pool). It's very frustrating to not have a
reliable way to get at least passable random numbers. The way I do this
in Perl 5:
BEGIN{
eval use Math::TrulyRandom;
if ($@) {
foreach my $file (qw(/dev/urandom /dev/random)) {
if (-r $file) {
no strict;
*truly_random_value = sub {
use bytes;
local *F;
open F, $file or die $file:
$!;
my $b;
sysread(F,$b,4)==4 or die
$file: $!;
close F;
return unpack(I,$b);
};
last;
}
}
if (!defined \truly_random_value) {
die No Math::TrulyRandom and no
/dev/(u)random\n$@;
}
}
}
I'd like to stop doing that ;-)
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: return of copies vs references
It occurs to me that I may have requested something before that would
cause more problems than it solves if implemented. So I have a
different idea that would hopefully be efficient, powerful, and easy
to learn. In short, make it work much like Perl 5.
The idea is Perl methods and subs will always return references or
scalars by default, just as method/sub arguments always take
references or scalars by default; so we have symmetry between the
in/out. And they would do this the same way regardless of the caller
scalar/list context.
If the writer of a method/sub wants to return a copy of a non-trivial
structure like a hash or array, they explicitly copy it and return
the copy. This is elegant because when they are explicitly copying,
they can also fully control to what depth in a tree-like structure
the items have either their values or their references copied.
For example, with the same $:foo, @:bar, %:baz attributes ...
These would return references to the structure root, in all contexts:
return \$self.:foo;
return $self.:bar;
return $self.:baz;
return \$:foo;
return @:bar;
return %:baz;
These would return a new structure with level-1 copies of the
elements, but if any elements are references then the copies point to
the same things in all contexts:
return $self.:foo;
return [$self.:bar];
return {$self.:baz};
return $:foo;
return [@:bar];
return {%:baz};
The exact syntax could vary. The above would scale to, say, explicit
2-dimensional copy similarly to Perl 5, like this:
return [$self.:bar.map:{ [$_] }];
return [@:bar.map:{ [$_] }];
Now, I am operating under the assumption here that in Perl 6, the
line between having a reference to something or having that thing is
blurred, and so there is no need to do explicit dereferencing; eg, no
@{} or %{}.
All that the caller context would then determine is whether what the
method/sub returned is flattened or not; the caller context would not
determine whether the method/sub returns a copy or a reference.
Question: Is there a trait for a sub/method that specifies whether it
forces a scalar or list context?
Any opinions on this?
-- Darren Duncan
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Thu, 17 Mar 2005 16:16:00 -0700, gcomnz [EMAIL PROTECTED] wrote: Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote: By the way, I think I've seen a few people suggest some sort of syntax-switching mechanism for Pod6. The day people have to think about what dialect of Pod they're using is the day Pod dies as a useful documentation language. 1. TMTOWTDI 2. Competition will help, not hinder. I for one would very much like to see a more Wiki and less POD like syntax. But that's a matter of taste. I will say though that I've never heard of anyone suffering because of how wide or narrow the [ and ] characters are in Wiki markup ;-). And MediaWiki's format is a beautiful example of a markup that has taken off and vastly simplified page creation and editing for over 100,000 editors at Wikipedia. 3. A format like Itext or Ctext is just plain ugly and verbose. I can't imagine why anyone defends that as something too keep. In understand there's a lot of love/hate emotion when it comes to Wiki's, but if we step back and ignore for a moment what the alternatives are will we really still want to keep that ugly inline syntax? (No disrespect intended, POD clearly predates of lot of other ideas about simple markups.) Marcus
Re: return of copies vs references
As an addendum, my idea would also apply to non-attribute variables.
If you say 'my %abc' in a method or sub, and later say 'return %abc',
then a reference to %abc will be returned by default.
So its not like I'm treating attributes differently.
-- Darren Duncan
At 3:27 PM -0800 3/17/05, Darren Duncan wrote:
It occurs to me that I may have requested something before that
would cause more problems than it solves if implemented. So I have
a different idea that would hopefully be efficient, powerful, and
easy to learn. In short, make it work much like Perl 5.
The idea is Perl methods and subs will always return references or
scalars by default, just as method/sub arguments always take
references or scalars by default; so we have symmetry between the
in/out. And they would do this the same way regardless of the
caller scalar/list context.
If the writer of a method/sub wants to return a copy of a
non-trivial structure like a hash or array, they explicitly copy it
and return the copy. This is elegant because when they are
explicitly copying, they can also fully control to what depth in a
tree-like structure the items have either their values or their
references copied.
For example, with the same $:foo, @:bar, %:baz attributes ...
These would return references to the structure root, in all contexts:
return \$self.:foo;
return $self.:bar;
return $self.:baz;
return \$:foo;
return @:bar;
return %:baz;
These would return a new structure with level-1 copies of the
elements, but if any elements are references then the copies point
to the same things in all contexts:
return $self.:foo;
return [$self.:bar];
return {$self.:baz};
return $:foo;
return [@:bar];
return {%:baz};
The exact syntax could vary. The above would scale to, say,
explicit 2-dimensional copy similarly to Perl 5, like this:
return [$self.:bar.map:{ [$_] }];
return [@:bar.map:{ [$_] }];
Now, I am operating under the assumption here that in Perl 6, the
line between having a reference to something or having that thing is
blurred, and so there is no need to do explicit dereferencing; eg,
no @{} or %{}.
All that the caller context would then determine is whether what the
method/sub returned is flattened or not; the caller context would
not determine whether the method/sub returns a copy or a reference.
Question: Is there a trait for a sub/method that specifies whether
it forces a scalar or list context?
Any opinions on this?
-- Darren Duncan
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
On Thu, Mar 17, 2005 at 05:04:53PM -0500, Aaron Sherman wrote: On Thu, 2005-03-17 at 12:28, Brian Ingerson wrote: The interesting thing to me is that all 3 syntaxes map over the same data model and thus are easily interchangable. It is, however, contrary to the spirit of POD for you or me to continue much further down this road (see below). Sam mugwump Vilain [...] is working on more formally defining the common model or AST that these dialects map to. My effort here was to try to PREVENT the proliferation (e.g. by Kwid and POD butting heads and ending up in a stalemate). I'll continue only as far as is needed to propose this in full as an example parser / converter, and then I'm going to stop. If Brian is correct about the fundamental interchangeability of these dialects (and I have no reason to think he isn't), may I suggest that the simple answer is to have a program which can translate from one dialect to another--just like we distribute pod2man, pod2html, and pod2text, we would now distribute pod2kwid and ajskwid2pod. --Dks -- [EMAIL PROTECTED]
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
[No, I'm not back; I'm just passing by. But I feel that I need to comment on
this whole issue]
Even before Brian announced Kwid, I was privately suggesting to Larry that
Markdown (http://daringfireball.net/projects/markdown/) was an excellent
evolution of mark-up notations and might be well suited to Perl 6. At
least...as a second allowable syntax.
And, in my view, Kwid kicks Markdown's butt in terms of its suitability for
Perl documentation. POD itself is brilliant and we should certainly not
abandon it, but it's critical to remember that POD is just an *interface* (or
Binterface, if you prefer ;-) to Perl's built-in documentation systems. I
strongly believe that Kwid is, for many purposes, a cleaner and less-intrusive
interface, and I for one will be using it (even if I have to build a kwid2pod
translator).
But frankly, I'd rather just be able to write:
=kwid
in place of
=pod
within standard Perl 6.
As for the larger issue of redoing pod, I've appended my notes on where the
Design Team left their discussions when last we discussed it. This might spark
some ideas (but note that I will not be able to respond to them any time soon
-- alas, bread-winning must, for the moment, take precedence over most of my
public activities).
Damian
-cut--cut--cut--cut--cut-
There would be a single consistent rule that says that every POD block
(except raw text blocks) has one of the following three equivalent
syntactic forms:
=begin TYPE OPTIONAL_MULTIWORD_LABEL_TO_END_OF_LINE
BLOCK_CONTENTS_START_HERE_AND_CONTINUE_OVER_MULTIPLE_LINES_UNTIL...
=end TYPE OPTIONAL_SAME_MULTIWORD_LABEL
or:
=for TYPE OPTIONAL_MULTIWORD_LABEL_TO_END_OF_LINE
BLOCK_CONTENTS_START_HERE_AND_CONTINUE_OVER_MULTIPLE_LINES_UNTIL...
first whitespace-only line or next pod directive
or:
=TYPE BLOCK_CONTENTS_START_HERE_AND_CONTINUE_OVER_MULTIPLE_LINES_UNTIL...
first whitespace-only line or pod directive
For example:
=begin table Table of Contents
Constants 1
Variables 10
Subroutines 33
Everything else 57
=end table
=begin list
=begin item *
Doh
=end item
=begin item *
Ray
=end item
=begin item *
Me
=end item
=end list
=begin comment
This is the most verbose way to write all this
=end comment
Or equivalently:
=for table Table of Contents
Constants 1
Variables 10
Subroutines 33
Everything else 57
=begin list
=for item *
Doh
=for item *
Ray
=for item *
Me
=end list
=for comment
This is a less verbose way to write all this
Or also equivalently:
=for table Table of Contents
Constants 1
Variables 10
Subroutines 33
Everything else 57
=for list
=item * Doh
=item * Ray
=item * Me
=comment This is the least verbose way to write all this
POD formatters could then be simply and consistently implemented by
inheriting from a standard Pod::Base class, which would provide a
C.parse_pod method that sequentially extracts each block construct (from
whichever of the three syntaxes), including raw text blocks (which are
actually just unlabelled C=for body blocks), and raw code blocks
(which are actually just unlabelled C=for verbatim blocks).
C.parse_pod would be something like:
multi method parse_pod ($self: Str $from_str) {
# Get sequence of POD blocks to be parsed
# Using standard rules...
my @blocks = $self.extract_pod($from_str);
# Dispatch each block to be processed by the
# appropriate method...
for @blocks - $block {
my ($type, $label, $contents) = $blocktype label contents;
$self.$type($label, $contents);
}
}
When each C.$type() method is called, both the label and contents would
passed as simple strings (either of which might, of course, be empty if
the corresponding component had been omitted from the block). The
(multi)method thus selected would then be responsible for
formatting/processing/whatevering the label and contents passed to it:
method head1 ($label, $contents) {...}
method head2 ($label, $contents) {...}
method list ($label, $contents) {...}
method item ($label, $contents) {...}
# etc.
Note that under this scheme the Perl5 syntax for:
=head1 Title here
=head2 Subtitle here
=head3 Subsubtitle here
=head4 Subsubsubsubtitle here
=item Bullet Item text
=cut
=pod
would mostly all continue to work (though, of course, C=cut and
C=pod would actually be dealt with directly within C.extract_from).
The most noticable change would be that something like:
=item Bullet
Text of item here
would now have to be written either as:
=item Bullet Text of item here
(an improvement,
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
Oh, and I forgot to mention: In the contents of any block, any line with '=' in column zero and a whitespace character in column 1, has those two characters removed when the contents are extracted. So you can write: =begin data POSSIBLE_POD_DIRECTIVES = = =doh -- Oh, dear! Oh frikking dear! = =ray -- A ravening beam of destruction = =me -- A name I call my invocant = =far -- A long, long way to Australia = =sew -- What I do with contention = =LA -- A place to follow trends = =tee -- I pipe to double streams = =end data To create the inline data: =doh -- Oh, dear! Oh frikking dear! =ray -- A ravening beam of destruction =me -- A name I call my invocant =far -- A long, long way to Australia =sew -- What I do with contention =LA -- A place to follow freaks =tee -- I pipe to double streams Damian
Re: New S29 draft up
On Thu, 2005-03-17 at 18:06 -0600, Rod Adams wrote: First off, thanks for the reply. Very nice work you're doing! I'll listen to proposals about how to support better randoms. For now I think Crand is a standard PRNG. Yes, absolutely. If I gave a contrary impression, I did not mean to. I think it's important for lots of historical reasons to have a repeatable (and hopefully somewhat standard) PRNG. I was saying that it would be a very nice thing if, come Perl 6, I did not have to write hairy code that checks for a module, and fails over to home-baked, OS- specific ways of getting good random data. This is a SEPARATE need from the need for a repeatable, standard PRNG, and should always operate off of the best source of entropy available to the program. Right now, that's /dev/urandom (for non-blocking hybridized entropy pool + PRNG) under most Unix variants and something like Math::TrulyRandom's setjmp/longjmp hack elsewhere. Speaking of which, there's a good reason to keep those two when you get to them ;-) One solution would be to adapt M::TR to Perl 6, and just pull it into the core. I'm just saying that it's a wide-spread need among a vast array of different applications (crypto, games, statistics, etc), and it makes sense to corize it.
Re: New S29 draft up
On Wed, 2005-03-16 at 02:18 -0600, Rod Adams wrote:
I just posted a fresh copy of S29 to:
http://www.rodadams.net/Perl/S29.pod
http://www.rodadams.net/Perl/S29.html
Couple more points from the docs (mostly to the list, but some to you,
Rod):
multi sub grep (Any|Junction $test : [EMAIL PROTECTED]) returns List {
multi sub join (Str $delimiter : [EMAIL PROTECTED]) returns List {
multi sub map (Code $expression : [EMAIL PROTECTED]) returns List {
multi sub reduce (Code $expression : [EMAIL PROTECTED]) returns List {
...
I presume that everything is being declared as multi because we wish
future subs to be able to insert special-cases for their own purposes.
The question then comes up: is there a reason that you would declare a
normal sub in library code... ever? Is plain sub no just a request for
mildly unusual optimization? If so, why not make it nomulti instead?
From the list of TODO:
Methods on numeric values (should be defined as pseudo-methods on
unboxed numbers):
chr
hex
oct
index
lc
lcfirst
length
ord
quotemeta
rindex
split
study
substr
uc
ucfirst
unpack
pack
pos
sprintf
caller
defined
prototype
ref
die
do
eval
exit
sleep
bless
gmtime
localtime
time
undef
vec
want
caller
Re: New S29 draft up
On Thu, 2005-03-17 at 20:47 -0500, Aaron Sherman wrote:
Methods on numeric values (should be defined as pseudo-methods on
unboxed numbers):
chr
hex
oct
Sigh... well, now I know what Ctrl-Return does in Evolution :-/
Ok, so what I was getting at was that the above three are methods on
numbers. The following are methods on strings:
index
lc
lcfirst
length
ord
quotemeta
rindex
split
study
substr
uc
ucfirst
unpack
You might also provide a procedural alias, but:
multi sub lenth(: Str ?$string = $CALLER::_) returns Int {
$string.size; # I think it was called that
}
These are real procedurals:
pack
Hopefully we'll have something more flexible and user-extensible... oh
and pie. We should have pie :)
pos
Grrr.. I can't recall what Larry had said about this... I know he
mentioned it once on this list. Maybe that was the ruleish pos?
sprintf
Ah blessed sprintf. Were we adopting a Pythonish implicit sprintf? I
forget. Would that impact the existence of explicit sprintf? Probably
not.
caller
Larry has said this is a rather hairy TBD in the past, though it might
have been discussed since.
defined
A universal (pseudo-)method?
prototype
ref
See defined.
die
do
Gone, I think no?
eval
exit
sleep
bless
A12
gmtime
localtime
time
undef
How will undef($x) and $x=undef compare in p6? Has that been covered? I
have a vague memory, but nothing swimming to the surface.
vec
This is pack with issues :)
want
caller
dup
Re: New S29 draft up
Aaron Sherman wrote: On Thu, 2005-03-17 at 18:06 -0600, Rod Adams wrote: This is a SEPARATE need from the need for a repeatable, standard PRNG, and should always operate off of the best source of entropy available to the program. Right now, that's /dev/urandom (for non-blocking hybridized entropy pool + PRNG) under most Unix variants and something like Math::TrulyRandom's setjmp/longjmp hack elsewhere. Speaking of which, there's a good reason to keep those two when you get to them ;-) One solution would be to adapt M::TR to Perl 6, and just pull it into the core. I'm just saying that it's a wide-spread need among a vast array of different applications (crypto, games, statistics, etc), and it makes sense to corize it. I would suggest wandering over to P6i and offering to write a Parrot version of M::TR, and see if they agree to put it in a distro of theirs. I have no idea what their policy is on getting packages into their version of core. But if it's there, then adding it to Perl should be trivial, regardless of what Perl has in core. It's also not a Perlism, so all the other Parrot languages would likely enjoy it as well. One thing I see looking at M:TR on CPAN is that it appears to only work on *nix machines. Making it cross platform would be a Good Thing. As for setjmp/longjmp: D:\Home\Perlperldoc -f setjmp No documentation for perl function `setjmp' found D:\Home\Perlperldoc -f longjmp No documentation for perl function `longjmp' found Sounds like they are using XS. (another reason to do it in Parrot). -- Rod Adams
Re: New S29 draft up
Aaron Sherman wrote:
On Wed, 2005-03-16 at 02:18 -0600, Rod Adams wrote:
I just posted a fresh copy of S29 to:
http://www.rodadams.net/Perl/S29.pod
http://www.rodadams.net/Perl/S29.html
Couple more points from the docs (mostly to the list, but some to you,
Rod):
multi sub grep (Any|Junction $test : [EMAIL PROTECTED]) returns List {
multi sub join (Str $delimiter : [EMAIL PROTECTED]) returns List {
multi sub map (Code $expression : [EMAIL PROTECTED]) returns List {
multi sub reduce (Code $expression : [EMAIL PROTECTED]) returns List {
...
I presume that everything is being declared as multi because we wish
future subs to be able to insert special-cases for their own purposes.
Something like that. Also, it's looking now like several of the
functions will be getting multiple definitions out of the box.
The question then comes up: is there a reason that you would declare a
normal sub in library code... ever? Is plain sub no just a request for
mildly unusual optimization? If so, why not make it nomulti instead?
To establish one single version of the function that will be called no
matter what. (within it's scope). A sub with a given name will mask any
multi of that name.
And they should be significantly faster to call.
-- Rod Adams
Re: New S29 draft up
Aaron Sherman wrote:
On Thu, 2005-03-17 at 20:47 -0500, Aaron Sherman wrote:
Methods on numeric values (should be defined as pseudo-methods on
unboxed numbers):
chr
hex
oct
Sigh... well, now I know what Ctrl-Return does in Evolution :-/
Ok, so what I was getting at was that the above three are methods on
numbers.
True, but they are not math functions. They are Num -- Str
conversions, and I haven't figured out where to put those yet.
You might also provide a procedural alias, but:
multi sub lenth(: Str ?$string = $CALLER::_) returns Int {
$string.size; # I think it was called that
}
Clength will be gone once I get there. It's there as a placeholder to
remind me to write the replacements. (Reminds me to write array versions
of them as well).
These are real procedurals:
pack
Hopefully we'll have something more flexible and user-extensible...
Proposals for replacement/reform should go to the list. But until the
matter is changed there, I'm sticking with the Perl5 usage. Yea, it's a
pain in the rump, but it can be invaluable in certain scenarios.
Do read the S09 sections Compact Structs and Compact Arrays first,
however.
pos
Grrr.. I can't recall what Larry had said about this... I know he
mentioned it once on this list. Maybe that was the ruleish pos?
A/S05 talks about it some. It's a Str property/method, mainly used with
rule matches. I think it's going to return an String::Position object
which can translate between bytes/chars/codepoints/graphemes
sprintf
Ah blessed sprintf. Were we adopting a Pythonish implicit sprintf? I
forget. Would that impact the existence of explicit sprintf? Probably
not.
It got renamed Cas recently, and will be pervasive, and in many forms.
caller
Larry has said this is a rather hairy TBD in the past, though it might
have been discussed since.
The function side of it is easy. S06 says The |caller| function returns
an object that describes a particular higher dynamic scope, from which
the current scope was called.
It's defining that object that gets a little interesting...
defined
A universal (pseudo-)method?
Fairly universal, yes.
prototype
ref
Cprototype I will apply to code refs. I'll have to think more about it
later.
Cref will be like Cdefined, but might get renamed to something like
C.meta.class
die
do
Cdie is staying, and only getting revamped to take into account the P6
exception scheme.
Cdo block is not a function, but is in S04.
Cdo subroutine is dead.
Cdo filename I'll tackle at the same time as Ceval. It's likely
staying in some form. I use it from time to time when I'm patching
together several automation scripts. (Remember that Perl gets used for
the quick and dirty as well as the big and elegant.)
undef
How will undef($x) and $x=undef compare in p6? Has that been covered? I
have a vague memory, but nothing swimming to the surface.
I think they're the same, but I really don't know.
vec
This is pack with issues :)
If nothing else, I plan on making a form that works on Int as well as
one that works on Str. I don't know how many times I've had to resort to
masks and shifts to do something vec should have done for me nicely.
Re: New S29 draft up
On Thu, Mar 17, 2005 at 06:11:09PM -0500, Aaron Sherman wrote: : =head2 Obsolete : : =item chop : : Chop removes the last character from a string. Is that no longer useful, : or has chomp simply replaced its most common usage? I expect chop still has its uses. Also, since $/ is going away, the meaning of chomp will probably change from chomping $/ to removing whatever was marked as the terminator by the input layer (which could even vary from line to line if the terminator was specified as a pattern). But mostly people will just have the input layer autochomp so they never see the delimiter. (The chomped delimiter could maybe be attached to the line as a property in case you're interested, if that's not too high an overhead.) Autochomping is one of the motivations for switching from while to for for the normal line input method, since while might think a blank line is false, while for only cares whether the next value is defined. Larry
Re: New S29 draft up
LW == Larry Wall [EMAIL PROTECTED] writes: LW oct and hex are arguably misnamed, since most functions are named by LW what they produce, not by what they take as input. I don't know what LW the replacement should be, though. Maybe it's not worth fixing. from_oct, from_hex which state what they do? or a more general from_base( 16, $hex )? and that could be curried into from_hex(). uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Junctions Question
Stevan Little writes:
my $a = 'a';
my $b = '';
my $c = '';
my $any_of_them = $b | $c | $a;
# this test passes
ok('a' eq $any_of_them, '($b | $c | $a) matches at least one a');
$b = 'b';
$c = 'c';
# this test passes ...
ok('a' eq $any_of_them, '($b | $c | $a) matches at least one a');
# but these two tests don't
ok('b' eq $any_of_them, '($a | $b | $c) matches at least one b');
ok('c' eq $any_of_them, '($c | $a | $b) matches at least one c');
That behavior is correct. Just as if you said:
my $a = 'a';
my $b = $a;
$a = 'b';
say $b; # a
This should work, however:
my $a = 'a';
my $b = '';
my $c = '';
my $any_of_them = \$a | \$b | \$c;
$b = 'b';
$c = 'c';
ok('b' eq $$any_of_them); # passes
That second $ might not need to be there. I don't understand exactly
how transparent references are yet.
Luke
Re: [Fwd: Re: [RFC] A more extensible/flexible POD (ROUGH-DRAFT)]
Damian Conway wrote: [No, I'm not back; I'm just passing by. But I feel that I need to comment on this whole issue] Thanks! This message has lots of useful information that I would have otherwise probably missed. It seems that the basic premise of the POD document object model gels well with that early design document, so I look forward to being able to flesh out the details. Using ^=\s to delimit a line starting with a = will interfere with the Kwid method of: = Heading foo Which I was imagining would be converted to a DOM tree that when represented in the Normative XML would look like: sect1 titleHeading/title parafoo/para /sect1 That's sort of DocBook style, and in fact I was thinking that for the internal representation, DocBook node names could be used where there is no other better alternative. Of course, non-documentation things like Test fragments or inclusions of external entities, like UML diagrams won't have a representation in DocBook :-). The uses of a leading = in a paragraph are fairly uncommon. For instance, when quoting POD you would simply indent it a bit to make it verbatim and there is no issue. I see a middle ground; that is, `=` quoting is only is allowed if it directly follows the initial POD marker; =head1 Foo = = =head1 = = = = =head1 That's just getting ridiculous Which I see as represented by; sect1 titleFoo/title para=head1 = = =head1 That's just getting ridiculous/para /sect1 Which of course would lose the ='s. But that's OK, because if you wanted verbatim you could have just indented the block. If you wanted to lead a normal paragraph with it, you'd just use the normally implicit =para (equivalent to =pod): =para = = = This is what a Kwid =head1 looks like As for going with =kwid to denote the starting of kwid, I have so far been pessimistically assuming that something like `=dialect kwid`, or `=use kwid` (as described in the design doc you attached) would be required. However, we could allow `=unknown`, where `unknown` is an unknown keyword, to try to load Pod::Dialect::unknown, and hope like hell it provides the Role of Pod::Dialect. While the `^=` escaping is active, the presence or absence of whitespace following the initial `=` will delimit breaks in paragraphs. This has to be so, otherwise the previous example would have been: sect1 titleFoo =head1 = = =head1 That's just getting ridiculous /title /sect1 Which is just plain silly. This follows what people are used to with POD - blank lines must be empty, not just no non-whitespace characters (an increasingly vague concept these days). So, the POD processing happens in 3 levels (note: the first isn't really mentioned in perlpodspec.kwid, which is a bug); =list - chunkification from the original source, into POD paragraphs, which may or may not include an initial `^=foo` marker. At *this* level, the only escaping that happens is the `^=` escaping. That's all that needs to happen while the code is being read, and for most code that is how the POD will remain, in memory, somewhere intermingled with the Parse Tree for the code, so that the code can still be spat back out by the P6 equivalent of `B::Deparse` - parsing of these raw chunks into a real POD DOM. Please, tired XML veterans, please don't get upset by the use of the term DOM, I think the last thing anyone wants is to have studlyCaps functions like `getElementById` and `createTextNode`. It is the tree concept itself which is important, and this pre-dates XML anyway. Strictly speaking, this step actually converts POD paragraph chunk events into POD DOM events. These can be used to build a real DOM, for instance if you need to do an XPath style query for a link (I was amazed that someone's actually gone and built Pod::XPath!), or they might simply be passed onto the next stage by an output processor with no intermediate tree being built. So, at this point, dialects get hooks to perform custom mutation of POD paragraph events into DOM events, and the arbitrator of this process ensures that the output events are well balanced by spitting out closing tags where it has to. They can store state in their parser object, but none of this state will be preserved past the parsing state. However, the nodes that they spit out after this point may still not be core POD, such as for includes or out-of-band objects. These hooks will be sufficient to allow them to hijack subsequent chunks that would otherwise be served to other dialects, ie, they can choose to arbitrate subsequent chunks. I'm aiming to make it so that it is possible for dialects to be round trip safe, by being able to go back from this DOM state to the original POD paragraph chunks. This would require dialects to play nice of course, but is a potential option to help make things like smart text editors be able to automatically syntax highlight POD dialects :). Linking will be in terms of this
Re: New S29 draft up
Larry Wall [EMAIL PROTECTED] wrote:
: Cdo filename I'll tackle at the same time as Ceval. It's likely
: staying in some form. I use it from time to time when I'm patching
: together several automation scripts. (Remember that Perl gets used for
: the quick and dirty as well as the big and elegant.)
But probably huffmanized to something longer like evalfile.
eval :file(somefile.pl6);
eval :string('{$^x + ' ~ $y ~ '}');
eval :file(otherfile.pl), :lang('perl5');
eval :string(lamda x: x + $y), :lang('python');
Since as long as we're huffmanizing, eval STRING deserves to be longer
than do STRING.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: New S29 draft up
Uri Guttman [EMAIL PROTECTED] wrote: LW == Larry Wall [EMAIL PROTECTED] writes: LW oct and hex are arguably misnamed, since most functions are named by LW what they produce, not by what they take as input. I don't know what LW the replacement should be, though. Maybe it's not worth fixing. from_oct, from_hex which state what they do? or a more general from_base( 16, $hex )? and that could be curried into from_hex(). 0xFF.dec() $num.dec() $num.hex() $num.base($n) ? I believe that some of these can already be handled by C.as(). I would like for this to be addressed. This is one item that has always confused me about Perl 5. -- matt diephouse http://matt.diephouse.com
