tement { 'ID' '=' }
rule endvalue { 'keyword' '(' ~ ')' 'pairlist' }
*rule unexpected { $ = (\N+) {
self.panic($/,"Expected statement but found '$'")
}}*
In other words: after the statements, we're either at the end of the input,
or else we found something unexpected, so capture it and then report it.
HTH,
Damian
opportunity it
represents, to be lost, just because it was initially directed at
someone who's currently drowning in other commitments.
So I thought I'd mention it here, in the hope that someone else
who is looking for a slightly unusual way to contribute to Perl 6
might find the suggestion worth considering.
Damian
ty it can offer. It's important that we
market both aspects...and to the right audiences.
For example, at OSCON this year I'm concentrating on the simplicity
of Perl 6:
http://www.oscon.com/oscon2014/public/schedule/detail/33839
Damian
get it into
schools, it would be a huge boost in its exposure and popularity.
I'm going to continue to refine my presentation, and offer it at any
educational institutions I can convince to host it in the various cities
I will be visiting over the next twelve months. We'll see if I get any
traction.
Damian
eadable/maintainable as:
my $selection = median_value_from( $bag.distribution );
Damian
Moritz wrote:
> To spin the tale further, we need to think about what happens if
> somebody writes
>
> multi foo(1|2e0) { ... }
>
> so now we have Int|Num. We could explore the most-derived common
> ancestor (Cool), or look into role space (Real, Numeric come to mind),
> or simply error out.
Or m
1: outer x
2: outer x
3: outer x
4: outer x
5: outer x
6: outer x
7: outer x
8: outer x
9: outer x
10: outer x
Damian
$x }
foo();
$x := $x_prime;
foo();
prints:
1
-1
...indicating that the $x in foo is bound to the slot, not to any var
implementation currently in the slot. The way I would have described it
is that binding is by name, not by reference.
Damian
5] $inner_state = 26
[call 6] $inner_state = 26
under Rakudo
BTW, Both the above "yes" answers are consistent with (and can be
inferred from) the previous explanation that:
my sub foo { whatever() }
is just a syntactic convenience for:
my &foo := sub { whatever() }
HTH,
Damian
> Thank you damian, i will apply that patch,
Much appreciated, Herbert!
Damian
" named =data. Instead, it
accesses the (potential) semantic block named =DATA...which is an
entirely different beastie.
BTW, S02 still has remnant mentions of $=POD and $=DATA, as well as some
other "antiquities" regarding Pod variables. I have attached a proposed
docpatch.
Damian
S02.patch
Description: Binary data
yary suggested:
> In a situation like this, I reach for a thesaurus
The standout from that list for me is: 'consonance'.
Second favorite is: 'gibe' or 'jibe'.
But the underlying operation is .ACCEPTS(),
so perhaps the operation should be referred to
as "acceptance" or "acceptibility".
Damian
get
an explicit Failure when it does happen, at least people will
know when the numerical computations don't work as hoped.
Damian
the sequence inference with a larger epsilon (or using
interval arithmetic).
Damian
e would be better off limiting the
deduction of *both* arithmetic and geometric sequences to starting lists
that contain only Ints and Rats.
Damian
fore compare the results with an
suitably larger epsilon.
That would not only be computational more justifiable,
I suspect it might also produce more "least surprise". ;-)
Damian
b # ...this sub matches: sub($prev_num) { $prev_num >= $b }
* used as an argument to an operator is a shorthand for constructing
subroutines,
where the * represents the subroutine's argument.
Damian
> Interesting... but it doesn't seem to work in Rakudo Star (2012.02):
>
>> @(2,5..10)
You need three dots, not two.
Damian
b
Perl 6 already has ^$b
e,g, ^100 > 0..99
> a: is the same as a..Inf
Perl 6 already has $a..* or $a...*
e.g. 3..* > 3,4,5,6,
> ::c is the same as 0:Inf:c
Perl 6 already has: 0,$c...*
e.g. 0,3...* > 0, 3, 6, 9, 12
> : is the same as 0..Inf
Perl 6 already has: ^Inf > 0,1,2,3,4,5,
Damian
return value in a signature (which syntax seems to fall out quite
>> naturally in any case).
>
> Or we simply reuse the convention from POST and CATCH that the
> interesting value (either exception or return value) is passed in as $_.
But that's less explicit and obvious than named return values! :-(
Not to mention much less "Nyah, nyah, Haskell...look what we've got!!!". ;-)
Damian
foo(Num $x --> Num $result)
will require { $x < 10 }
will ensure { $result > $x }
{
return 2 * $x;
}
}
class B is A {
method foo(Num $x --> Num)
will require { $x < 100 }
{
return $x+1;
}
}
And, yes, this does indeed imply a syntax for optionally naming the
return value in a signature (which syntax seems to fall out quite
naturally in any case).
Damian
ly should
have been called INIT(), but that keyword was already taken.
> "you must write your own BUILD (as above) in order to present private
> attributes as part of your initialization API."
>
> And that's not so good, because it forces BUILD to be used for
> initialization,
...which is precisely what it's supposed to be for. :-)
Damian
larly, one could just create
a role (possibly parametric) to handle all the boilerplate
and then mix just it into any class that requires it.
Damian
;
then we've failed to make Perl 6 even as usable as C++, which is
a tragedy.
I sounds like I simply misunderstood yary's problem, but I'd be
very glad to be reassured that's the case. :-)
Damian
e current semantics of object initialization.
Damian
arts
of the spec use underscores, newer parts use hyphens".
And I'd like there to be a more consistent approach than that
(though I don't really care what it actually is).
Damian
consistent and teachable rule?
And why is this entire message written in questions?
Have I simply been watching too many "Whose Line Is It Anyway?"
episodes?
Damian?
ould result in the safe behaviour (i.e. full encapsulation).
You ought to have to explicitly request anything else.
One of the *big* selling points of Perl 6 is the prospect of "OO done right".
Leaky encapsulation ain't that.
Damian
#x27;s not returning eigenstates, and some of us believe it
*can't* every return eigenstates, then it certainly shouldn't be called
C<.eigenstates>.
Damian
function does one consistent thing
(regardless of the specific types of its operands)
whereas I want:
A given operator or function does one thing
(consistent with the specific types of its operands)
In other words, you seem to be arguing for monomorphism, whereas I'm
definitely arguing for polymorphism. Neither is inherently better, but
one is inherently more powerful. While I deeply respect your
position, I'm going to keep arguing for that more powerful alternative.
Damian
But that's just
"having a side-effect", which we already know is inappropriate for
junctions (and hyperoperators, and autothreaded loops, and pretty much
any other kind of parallel construct).
Damian
I have absolutely no objection to
.eigenvalues() returning a Set, rather than a List. Indeed, I think it
would be even more valuable that way.
Damian
sues. Other possibilities are:
select(@values) < one(3..7)
those(@values) < one(3..7)
whichever(@values) < one(3..7)
itemize(@values) < one(3..7)
extract(@values) < one(3..7)
...of which, only C really seems a good alternative.
Any other suggestions most welcome!
Damian
embedded eval. But, in the
name of maintainability, I probably should benchmark it both ways.
Thanks for pointing that out, Ben.
Damian
decision to make junctions behave "normally" wrt
comparisons. They're much easier to understand the way they are now.
I am merely trying to reintroduce the useful extra concept of a
collection of numbers that filters under comparisons. But if people
aren't comfortable, I'm happy to leave it as a module (especially since
it's already written).
I would hate this (very worthwhile) discussion to distract from the key
point of the original post: namely, that the private C is
misnamed, and a public C<.eigenvalues> is missing.
Damian
(my $is_valid = Num & {$_>0} | Str & /zero|one/).
And, of course, they're in the core because there's no point in having
that much power and usefulness if it's not fast too.
Damian
eir functional or operator-oriented alternatives.
I'd like these in the core language (for performance and universal
accessibility), but if not, I already have a nearly-complete
implementation of a module implementing them, which runs successfully on
the current release of Rakudo*. I appen
~~ UNACCEPTABLE {
say "Unacceptable password. Don't use any of these:";
say UNACCEPTABLE.eigenstates¬».fmt("\t%s\n");
}
If nothing else, we really do need to rename the current C method.
Damian
PS: I also note that the most recent release of Rakudo* defines the
C<.eigenstates> method as public, which is inconsistent with the
current specification. That probably needs to be fixed as well.
ify successful patterns of use
and steal^Wborg^Wborrow the very best available solutions.
Damian
. :-)
As long as it's easily searchable and vaguely pejorative (e.g. has the
work MONKEY in it).
Hm. You need to use MONKEY_TYPING when you're monkeying with typing,
so maybe when you're monkeying with what can be seen (and abusing Perl
6 as if it were C)
then you need to use MONKEY_SEE
Damian
that have accessors.
I'd be happy with that.
> Maybe .new should also default to his behavior.
I'd be happy with that too.
>> Then Damian's position (which I support) is supported and so are monkeys.
>
> Ook ook!
"Apes! I meant apes!!!" ;-)
> Moritz
> (who actually writes Perl 6 code on a nearly daily basis).
Damian
(who does too)
be properly encapsulated and stable, unless someone explicitly
declares they are monkeying.
As it stands at the moment, it's not clear to me why we even bother with
opaque objects, if it's going to be this trivial to break encapsulation.
Damian
Carl wrote:
> For what it's worth, we had exactly this discussion a couple of days
> ago on IRC. I represented your views above, Damian.
Thank-you for that.
> As long as C<.perl> works the way it does, there can be no real
> privacy.
Sigh. That is indeed badly bro
ractice are explicitly marked in a
consistent and easily searched-for manner?
Damian
l have to rewrite when
the Pod spec gets updated. Or, alternatively, to require all
Pod parsers to be infinitely backwards compatible across
all versions. :-(
Damian
Aaron wrote:
> I dislike "reserved" in this context, but understand why the namespace has
> to be shared. For config options, I'd say anything should go, but people
> inventing their own config options should be aware that across N release
> cycles, new options may be introduced.
...which means t
available to users and the parser should simply
accept them without complaint and include them in the internal data
structure it builds, whereupon they will be available to user-defined
Pod extensions.
Damian
so I certainly wouldn't
object to having the index of the next generated element readily
available as an explicit variable in a series' generator block.
That would make all manner of evil both easier and cleaner. >;-)
Damian
allow those (apparently elite few) who
can correctly use a hyphen to correctly use the hyphen, whilst the
shambling masses can just randomly type underscores or hyphens between
each word, as their atavistic whims dictate.
;-)
Damian
)
And is it really so hard to teach: "use underscore by default and reserve
hyphens for between a noun and its adjective"? Perhaps it *is*, but
then that's a very sad reflection on our profession.
I'm certainly not saying we mightn't collectively find a better (more
useful) rule, but that one doesn't strike me as particularly hard.
Damian
h the C<.time-zone()> method
(or, preferably, we should jut bite the bullet and go with C
throughout).
Damian
re like the constant declarator
syntax, I'd have thought:
enum Perms = 1,2,4...*;
was a much closer analog (and syntactically cleaner too).
Damian
t it provides the necessary flexibility and tools to
allow someone to implement a new datatype and declarator syntax and
integrate them seamlessly into the language, without having to redefine the
language itself...or modify the compiler.
Damian
# Also declares: subset Perms of Int where 0 .. [+|] @constant_values;
# Hence allows:
my Perms $perms = Read +| Write +| Mutilate; # Okay
my Perms $bad_perms = Read +| Write +| 42; # Error
Aw heck, now that I've specified it, the implementation is just a SMOP.
Forget I asked. I'll just write it myself! ;-)
Damian
series operators; it seems a shame not to use
> them for powers of two when appropriate.
I certainly agree there.
Damian
rs can still easily convert the final set to an appropriate
bit-pattern when it's time to pump the results out to the hardware.
Damian
nstantly have to be reinvented.
If anyone can think of a cleaner way to do it within the current semantics,
I'd be very happy to hear of it. I'm jetlagged and bleary from a full day of
teaching and I may well be missing an obvious answer.
Thanks,
Damian
012_345_678_901
);
if you like to group your thousands for better readability.
With adequate constant folding, both of those are still compile-time constants.
Damian
eparately.
That interpretation is not consistent with the other examples
immediately above and below it.
Damian
Carl observed:
> Partly that is because documentation isn't at the forefront of things
> that need to be implemented for Perl 6 to be useful, so it's kind of
> lagging behind the rest.
>
> Partly it's because Damian is the "owner" of that synopsis, and he
Pod is rendered. To do that,
they need to be able to walk the documentation tree (a.k.a. $=POD) and
extract useful information from any class, code, or variable declarations
associated with a particular comment-style node in the doctree.
Damian
oo, if necessary, but that would then make the
performance hit hit very hard indeed. I suspect that it would be better
to preserve the Poddish parts of the AST structure and just have them
transmogrify into the appropriate Pod objects on demand.
Damian
be maintained past the
> creation of the AST.
Unfortunately, it is. Perl 6 defines that Perl 6 programs can always
access their own Pod at runtime (via $=POD). You probably can't even
optimize the information away in the absence of any compile-time
reference to $=POD, since there are plenty of symbolic ways to refer to
$=POD at run-time.
Damian
.for those who can handle it.
I guess my point is simply that not everyone can handle it. Just as not
everyone could handle raw inside-out techniques, which is why Class::Std
was written in the first place.
But, as you say, this is now far off-topic, so let's leave it at that.
Damian
in particular the recommendation to use Class::STD/etc is outdated,
> and people should use Moose instead.
There is no doubt that Moose is an excellent and very advanced framework,
but both the above assertions are highly debatable, especially if you
s/moribund Class::Std/actively developed Object::InsideOut/.
Damian
lename) {...} #=>[m1] #= Here's a
> block for A.
> my Bool method close () {...} #=>m2
>
> And given that brief names are going to be preferred, this could
> result in very compact, yet still readable, combinations of declarator
> aliases and blocks.
Yes, this is a definite advantage of the proposal. No question.
But I'm still concerned that the two syntaxes are just so similar.
I'll continue pondering the trade-off.
Damian
?FILE>.
The latter. Variables are just too common in documentation to
have (some of) them interpolate automagically.
> Or would you have to alias the variable and then refer to it?
No. I envisage that A<> would recognize an alias starting with a sigil,
and "auto-alias" it for you.
Damian
bility would be to allow empty A<> tags in a
> declarator block, with 'A<>' being replaced with the name of the
> declarator to which the block is attached:
These are both very useful ideas.
I'll ponder them carefully in preparation for the next revision.
Thanks, Jon!
Damian
$tree.size() == 1 :ok;
}
Not to mention all of the clever uses I can't think of yet. ;-)
Damian
Smylers pointed out:
>> * Hence it must always parsed using full Perl 6 grammar: perl6 -doc
>
> Having a multi-character option preceded by a single hyphen doesn't play
> well with bundling of single-character options...
You make many good points. Changed to: perl --doc
Thanks,
Damian
tions to
the general syntax.
However, I had originally thought that we should have =alias and
=dealias directives to delimit code extractions. In the end I liked the
use of the code's own delimiters better, but I guess if people preferred
to have two directives as delimiters, we could consider that instead.
Let's see what others think.
Damian
sure we *will* have a safety mode of parsing Pod (maybe:
perl -undoc) But it can't be on by default, otherwise no-one can
write anything but vanilla Pod and expect it to work. It's like
saying that 'use' is potentially dangerous (which it *is*) so can we
have it off by default. In Perl, the answer has to be "no".
Damian
g the code block alias, are the outermost curly braces
> considered to be part of the ambient code?
Yes. All ambient code is actual code.
> Why is =END a block, and not a directive?
Damn good question. I can't think of any reason off the top of my head.
I'll need to ponder that.
Damian
see the logic of #`[= but I just can't see the aesthetics of it.
I'd much rather have to only look at the second character to determine
it's Pod, not a vanilla comment. Besides, I think people will simply learn
that #[ is an embedded comment, where specifies
what kind of comment it is (I can certainly envisage other kinds
besides just vanilla and Pod-flavoured)
Damian
gt; Having to use aliases at all to refer
> to things that the Perl 6 compiler already has a name for seems like
> an ugly/heavyweight/suboptimal approach.
I think aliases are essential. We need a way of referring to ambient code
within Pod, without the Podder having to write more code to get it.
Damian
#= some Pod
>
> Then &fu is a multi, not a particular candidate. Does it actually
> attach to the .WHY of the candidate? Or of the multi?
Of the particular candidate. I'll make that clearer.
(If you want to document the entire multi, attach the documentation to
the proto.)
Damian
: Initiate a specified spell normally
.kast(Spell $s) : Initiate a specified spell abnormally
Damian
Raiph Mellor hyperpunned:
> With this whiny man exchange ultimately having bourne supreme fruit,
> the apocalypse watch for the post damian weekend begins...
ARRRG!
Damian ;-)
h hope that this
new revision will satisfy The Overmeer Desiderata [1] too.
Damian
[1] Sounds like a Robert Ludlum novel, eh?
degree of context discrimination you need.
Further to that idea, I'm actually planning to attempt to port
Contextual::Return to Perl 6 in the next few weeks.
Damian
ncise explanation of both these senses of xor.
Damian
racter is a
small price to pay for perfect SWIM (and not just "Say What I Mean",
the real benefit is the other SWIM: "See What I Meant").
Of course, this assumes that @a.=shift, @a.=push, etc. aren't actually
implemented with a copy-modifier-and-replace, but are optimized to
in-place mutators, under the hood.
Damian
operator (except for non-associating operators) can
be surrounded by square brackets in term position to create a
list operator"
and has an example of actually implementing the &prefix:<[+]> operator.
Damian
x:<+>, how do I refer to the Code of the
> list operator [+]?
&prefix:<[+]>
Damian
o arguments, '[+]' can accept
> an arbitrarily long (or short) list of arguments.
And since &[+] is &infix:<+>, that's how it knows. :-)
Damian
al.org/syn/S03.html#Nesting_of_metaoperators
>> PS: A really mean, but very effective, way of emphasizing the ease,
>> expressiveness, compactness, and readability of Perl 6 code is to
>> take each of the examples and show the same thing written in Java. >;-)
>
> It might be appropriate to compare some examples with Ruby or Python.
Only if the comparisons are suitably invidious. ;-)
Damian
ic {
token Literal {
+
|
}
}
* "Only perl can parse Perl 5" but "Even Perl 6 can parse Perl 6":
given $source_code {
$parsetree = m:keepall//;
}
And that's without even mentioning all
dent of the source
> code, and need not be in the same file.
That's certainly true of your proposal. However, many might argue that
one *disadvantage* of using Pod blocks plus :name<> that way is that the
documentation is independent of the source code, and need not be in the
same file. ;-)
Damian
text (i.e. how many elements are expected back).
That information can be very handy for optimization. And, yes, C::R
would already
handle it if I could think of a clean interface that was implementable
in Perl 5 without source filters.
Damian
', 'bar')))
> 2) Also, is the following true for nested 'all' junctions? viz.
> all(... , all('foo', 'bar')) === all(...,'foo','bar')
Yes, with a similiar "directly" caveat, as above.
> 3) Conjecture: The following is true of all junction types, eg.,
> junc(..., junc(...)) === junc(..., ...)
No. As Patrick so ably pointed out, this is not true for 'one' nor for 'none'
Damian
uot;) in Perl 6, there will soon be a module
that facilitates them. ;-)
Damian
n't be surprised if all compound junctions can flatten into
> equivalent simple junctions.
In general, they can't; not without changing their meaning.
Damian
ar that was definitely not the case.
Damian
t a general TEST
{...} block (which only runs if testing is enabled) might be valuable?
Damian
read-only,
whereas a $!foo attribute defaults to read-write.
Damian
rely to point out that Larry's response in this thread seems
to revise that proposition somewhat, and I would like to suggest that, if
:foo() is now to mean something more sophisticated that :foo(undef), then we
should still find a "cheap" way of building adverbs with undef values.
Damian
Moritz Lenz wrote:
There are some tests for List.uniq in the test suite, and pugs
implements it, but it's not in S29.
Damian seems to have though we should have it.
So should we have it?
I still think we should. If only because I've seen it re-(mis)-implemented so
many times.
those in the Perl community who are
either building our future or (just as importantly) maintaining our present.
But injecting UCE into such discussions does not further that goal, and I am
sincerely sorry that it was done in my name.
Damian
Just a brief note to reassure Mark--and everyone else who's interested--
that I'm not ignoring his post...I'm just fully occupied at the moment
with other (paying) work. In the meantime I'm thinking very carefully
about what Mark suggested. I'll reply properly as soon as I am able.
Damian
the necessary syntactic extensibility and the essential
building blocks (parser, DOM, module support) required for the
proponents of each individual documentation philosophy to create a
mark-up system and supporting tools best suited to their specific needs
and objectives.
Damian
1 - 100 of 1296 matches
Mail list logo
