Hailo

 view release on metacpan or  search on metacpan

t/lib/Hailo/Test/TimToady.trn  view on Meta::CPAN

except you can't write $fooxxx 3
and 3xxx will get you funny looks even if the computer groks it
but that's just another reason it has to be a weird infix rather than a postfix.
or we force people to write .xxx
so I think what we want here is some generalization that inserts Inf on the right side.
and I think it's the fact that * with no argument means "Whatever".
3 xx *    0..*  take Whatever to mean positive Infinity (and Beyond!)
*..* would then possibly mean -Inf..+Inf.
is no term starting with ..
is the same operator that means Any in [*;0..5;*]
aufrank: if you want to exclude Inf, sure.
except that ^ has to be contiguous with ..
or you've just said 0 .. 0..^Inf
I think this is a simplfication over ...
fine, it's dead
.oO(baskerlell)
people are so used to * meaning Whatever in globbing.
copy us, xerox
this is a role that * is already being used for.
generalize that to "behavior selected by the associated operator"
argumentless * is just a Capture of the Whatever idea.
indeed.
that's how it already works in subscript slices
It is backtrackless if you ignore whitespace.
0..Whatever means Inf
yes
No, it's really 0..ArbitrarilyLarge
but we can translate that to +Inf for practical purposes.
Computers can't understand infinity any better than we do.
on the right side of .. it is.
Okay, how about ArbitrarilyLargeEnough instead?  :)
Maybe define it as the first uninteresting number...
oh wait...
"foo" xx *
my ($a, $b, $c) = 1 xx *;
$x[*;0..5;*]
there Whatever means whatever the domain of the key type
%x{*;'a'..'z';*}
see S09
rand *   :)
for * {...}
for Whatever {...}
could be the new =<> if we go with Audrey's new idea.
/foo/ ff *
flipflop
in this case it means "false"
It doesn't--it always means Whatever.  :)
but that's sophistry...
you mean like @foo changes meaning under + vs say
I don't think so.
to2: I'd expect it to do much the same as +(Any), which is to say,
probably throw an exception.
which certainly falls under the rubric of "Whatever
"
In general the * prefix just means "splat something in here that is not directly specified"
I don't think anyone can look at 0..* and not grok it.
s/anyone/anyone not seriously damaged by earlier exposure to computer culture. :)/
Make me one with *..*
In a selector when you're too lazy to say Num.
that's another reason for it.  'a'..*
the endpoint is *not* Inf.
It's...its...er...
Whatever.
Sorry, I already called the colon.
Whatever...
right.
"Whatever" xx *
It googles for Whatever and starts replicated the I-feel-lucky page
s/ted/ting/
was just wondering about XXishness
not to have it.
:)
I think we can just get away with recognizing a closure on the left to mean that.
{ say "Whatever" } x *
and you want that because...
Juerd, actually, we do have map EXPR, LIST now.  That's *all* we have.
map {...}, LIST is just a selector in the first arg.
"selector"
about an hour ago we just through talking about grep(0..3, @nums)
pick the entries that match the selector.
a selector is smart matched.
a smart match against a range checks to see if something is in that range.
selectors return boolean.
right, sorry
I mentally translated your map to grep
but it's still the case that the syntax is map EXPR, LIST.
it's just map does something different.
you could probably use anthing that maps though, like a hash.
map %xlate, @values
how can you tell what type is wanted in the presence of ubiquitous MMD?
I guess there's a return sig anyway
Item --> Boolean for instance
We'ver already named those Selectors
I agree that EXPR is not specific enough.
If you have opinions on that subject you should help Damian and Ingy with the revised S26, whatever it's called these days...
pugs/docs/Perl6/Spec/Documentation.pod or some such.
on the other hand, the document structure will be availabe to the surrounding code.
so anything that is naturally code goes in as code, and anything that is naturally doc goes in as doc, but is still available as if you'd put it in as code.
is documented--
%=DOC++
the document model will even give you the nearby comments if you want smart comments
so just use the shiney new #{...} for your inline docs.
how...literate...
yes, except they can't start in the leftmost column.
happened a week or two ago
see S2
cool.
you get to pick your delimiter with #{}, so you can pick something distinctive.
try again. :)
all defined in S2
nto?
defined such as to include <>
despite not being Ps/Pe
basically, "bracketing characters" in Perl 6 are now defined to be either Ps/Pe pairs or bidirectional mirror pairs.
:)
Yes, multiples are consistently supported, though the semantics of <<>> are special in some places.
[[[*]]]
we're fixing that.
get involved in the Documentation.pod rewrite if you like.
legal
Hey, Unicode has to be good for something...

t/lib/Hailo/Test/TimToady.trn  view on Meta::CPAN

I was actually a bit serious earlier when I said
for Whatever {...}
no, Whatever is what it means.
surface syntax is still *
just in that context means *<> or *$ARGS or some such
dunno.
if empty postfix <> still means ARGS though, and if we ignore @<foo> from Match objects
then @<> could mean all the lines from ARGS
but @@<> would mean to keep the separate file's lines as a separate dimension.
but it depends on swiping empty <> from @()
which we could conceivably do, since the empty key doesn't mean anything anymore to $/
but it's a little confusing that @<foo> means $/<foo> when @<> means *$ARGS
mmmm
explain that to a five-year old
'Course a 5 year old will simply take on faith that "for * {...}" works and run with it.
groups?
yeah, tell me about it... :/
yes, I did
for + {...}
for ? {...}
for **{0..10} {...}
that...almost works...
for "do" | "do not" {...}
for "better" | "worse" {...}
It's probably too cute, mostly because the context is too diffuse
I could more easily believe that * is the ARGS iterator if it were used like =* or @*
...
?('b'|!'b') maybe
hmm *..'x'
I wonder what a negative string looks like?
/foo$/
or would that be /oof$/
bingo
surly \$foo\
\$oof\ I mean
pity f doesn't have a bidi mirror...
I'm not sure you can ! a range...
though I suppose it could be useful.
Oddly, $a..$b is contiguous, but !($a..$b) wouldn't be...
that would generally be clearer, i suspect.
On the other hand, as a general selector...
I guess you could always pass { $_ !~ $range }
say not $a .. $b   # -Inf, -Inf,-Inf,-Inf,-Inf,-Inf,-Inf,-Inf,...
It's a set of data values along with a hint about their logical relationship
Currently junctions are only discrete values, whereas ranges are (in the abstract) continuous.
rather, use of a junction is a promise that the "legs" of it can be calculated in parallel without interference.
Unlike hyperops, even ordering is lost.
even completeness is lost, in the sense that a hyper goes to completion
while a junction is free to short-circuit any way it likes
as long as the logical relationship can be proven.
so $a ~~ 1 | 2 | 3
can quit as soon as it finds any match.
no
it can quit as soon as it finds two matches. :)
if 'x' ~~ any(@foo) { say } can quit on one match
as can all(@foo) if it's false
or none(@foo) if it's true
nothing like that
well, that's exactly what $0 is...
I doubt .. would know what to do with StrPos, but StrPos might figure out what to do with ..
and .. could exclude the endpoints. :)
I once had a font with square periods...
i wasn't making fun of your bad English
I was making a pun.
I do that sometimes...
unfortunately...
Fortunately, time is kinda uniform (to the first approximation),  Unfortunately, string lengths have multipathing problems.
but it certainly the case that we should prefer APIs that deal with the strings themselves rather than indirectly referring to them via their locations
Well, and byte boundaries are likely to be the internal form a StrPos in many cases.
but you might have a pos in a string that doesn't even *have* bytes.
espcially now that we can do things like @foo ~~ /stuff/
you get handed a string with its minimum abstraction level set to, say, codepoints, and you aren't allowed to know it's repr internally.
Or you are matching an array of token objects.
That's the Str vs Buf distinction.
that's correct.
Unicode doesn't do integers.
Even UTF-16 is not a fixed-width representation.
And at grapheme level, even shoving everything into UTF-32 doesn't help
no, they just think it makes sense...
And it does make sense, but not in the way they think it does.
They weren't using Unicode before.
The reason the default level is graphemes is because that's closest to their intuition of what was happening before, even though that's harder for us.
You can use integers at grapheme level, just as you can use integers in Perl 5 at codepoint level, but you have to do tricks to deal with variable length characters in any case.
that's yet another definition of length.
which has nothing to do with any of bytes, codepoint, graphemes, or characters...
it's just a definition that depends on knowing your output device.
or not caring.
you'll note that HTML gets along fine without %s.
basically, for interpolation, not sizing.
interpolation
q[<a href="{uri_escape($url)}">{encode_entities($url)}</a>]
don't deny it.
yeah
q:url($rul)/.../
s/ru/ur
Didn't we tell you?  Perl 6 is an attempt to re-invent PHP...
I think we should write it all in lisp...
declarative programming++
as long as it's all imperative underneath :)
no it doesn't
<<..>> do shellish quoting syntax
why would we want to duplicate " ' $foo ' "
good gad no
just the quoting
and that not including backticks.
it's already that, to2
a grammatical category installs two longest tokens, one ending with < and one ending with {
fixing long dot would involve changing the first character to something other than dot.
right
right.
tokens would be elk :{foo} .antler :{bar} so I believe so.
(using token to include supertokens)
I think I know which is more important...
and it isn't lining up long dots
unfortunately there aren't any convenient ASCII characters left for changing the opening of the long dot.
well, I have to run off for most of the day.
As an option, though, a Latin-1 would work along with ". ".
ta &
something that wouldn't be wanted for infix!!!!
really &
yay, now passing over 11,000 again.

t/lib/Hailo/Test/TimToady.trn  view on Meta::CPAN

depends on which canonicalization you've used
in general as long as all your data uses the same canonicalization, you don't have to worry
yes
see http://unicode.org/reports/tr15/
people argue about whether NFC or NFD is better.  the answer is that they're better for different things
NFC is more compact, and NFD is more future proof.
but NFD compresses down about as well as NFC does, since the information content is the same.
NFC is likelier to give you something close to one codepoint per grapheme for most national character sets.
NFD will split out accents and such to combining characters, so you're very much in the realm of a variable width encoding in terms of codepoints per grapheme
the default Perl approach is to simply claim that the abstraction will be maintained, even if you have to do normalization on the fly internally.
given that Perl may be pulling in both NFC and NFD data, there's something to be said for the lazy approach.
it does mean that $a eq $b may be doing more than just memcmp() though
but yes, to the user there is no encoding, at least until they have to send it to an API that needs to know.
probably.  we're looking at doing something like in http://www.seas.upenn.edu/~lipeng/homepage/unify.html
westymatt: would you like a commit bit?
*contend
and the thread continuation monad may provide similar for thread vs event issues
assuming we take the approach of http://www.seas.upenn.edu/~lipeng/homepage/unify.html
someone else mentioned it first a while back here...
hmm, must have been somewhere else I saw it first...colabti only sees your new entry.
maybe it was in the chatterbox
yeah, audreyt, http://colabti.de/irclogger/irclogger_log/perl6?date=2007-02-09,Fri#l363
well, it succeeds in the sense that it doesn't blow up...
There are still lots of infelicites, such as the fact that only one of each multi regex shows up...
which is likely something the "cheat" script will have to deal with anyway for bootstrapping.
putter: that's the section written by TheDamian.  I'll have to think about it some.
putter: I think you're missing that the latter are bindings to something quantified and hence always would be an array anyway.
the first binding is to an unquantified thing
I don't see the problem
there are constructs that for $ to really be an array
but @ just says, "push whatever you find even if if it's just one thing"
s/that for/that force/
'tis quite possible I'm being dense, of course.  happens to me every now and again...
bbl &
um, that wasn't me...
um, who is being me?
@moosages
specbot seems to be going nuts and rehashing old stuff
maybe the backlog will explain...
looks like specbot is reminiscing
or perhaps its life is flashing before its eyes as it dies...
diakopter: sure, problem was always that I had too many answers...
shh, you weren't supposed to notice that.
are you implying that spec changes made in haste result in negative karma?  :)
gaal: lol, e.e.cummings were a good poets
we are amused
@tell putter I like your little chart, and it reminded me that @x:=[...] only captures text, which I'm sure p6std violates in lots of places.  I also think I like your infix:name idea, at least for generic matchers with no fixed sym.
@tell putter however I will probably change the part about "flattening" into the more modern lazy flattening that can be undone by @@ context.
heh, I just realized we're using "is context" for two completely different things
we used to have "is context(Scalar)" on parameters, which we've all forgotten to remember.
which means that particular usage should probably die
no, it collides--I've been putting "is context" on parameters to turn them into environmental vars
and the fact that the "is context(Scalar)" section has a big disclaimer at the bottom that it doesn't work half the time...
is another strike against it
should probably just be relegated to special macro processing anyway.
since it's something that has to be known at compile time.
so I'm just going to delete it.
putter: note in my message I'm thinking about changing it to lazy flattening undoable by @@
you can ignore the symbol stuff in S05, it's already obsolete
in fact, I just now deleted it
Range.max just returns the endpoint, ignoring :by
so pugs is correct
Schwern++
the "Perl 7" discussion, I think
not to mention the strange regex ideas
There's little wrong with Perl 5 today that wasn't already wrong in 2000 when 361 RFCs were written...
I think of them more as macros than methods
WHICH is more likely to call stringify or some such
depends on the MOP I think what the meaning of object identity is
[particle]: you mean on .max?
[particle]: I'll need to think about that
< svnbot6> r15382 | audreyt++ |     vv('foo').HOW;      # Str
arguably that should return ^Str rather than STr
*Str
I think it needs to stringify to ^Str to avoid confusion with the Str prototype
hmm, I wonder if (1..10).push should return (1..11)
Range is currently mutable
and we always said you could iterate a range on either end, but never said how.
hmm, maybe .minmax is a no-op, and infix minmax should always be done with range objects to preserve inclusive/exclusive distinctions.
a PDL programmer would expect that to work, but I'm not sure a mere mortal would
S03 has always said it's mutalbe
*mutable
the place where it says "Range objects are lazy iterators"
there's no such thing as an immutable iterator
I suppose if you're doing the problem where the fly flies back and forth between two approaching locomotives...
you'd end up with (3..0:by(-1))
the problem with using two Scalars is that you have to keep the inclusive/exclusive information out-of-band.
and I think people might rather write $a..^$b minmax $c^..$d than using lists of two elements.
for a given Range construction
I think so
at construction time
1..100:by($x) is fine
we don't have to decide whether .min and .max swap ends until construction time
when we see whether $x is negative
well, you'll wait a long time if rand returns 0 :)
but 0..1:by(0) is no worse than 0 xx *
bbl &
my make smoke loops on two of the regex tests
audreyt noticed it last night too
and left a message for fglock regarding it
194.145.200.126
this is #perl6.  I don't know what makes you think you'll get Haskell help here.  :)
oh, well that's okay then...
morning audreyt
how'd it go a gooooogle
did they like it?
did they ask any good questions?
ya think?
sides, a googol is only 10**10**2
saw a short talk from Pike mentioning it here in MV
though it was mostly about stats gathering
er, not that either without parens...
pretty much
should I add anything to Perl 6?  :)
things with whitespace as syntax maybe?
we'll just have to write a stone-age to space-age translator for them.  :)
but it looks like not much of anyone is signing up to be a mentor
ah
that I'm willing to help mentor.  :D
they're putting a Python grammar onto Parrot under the name of pynie, if you hadn't noticed, or even if you had.
given it's in pge it'd probably be pretty easy to filch.

t/lib/Hailo/Test/TimToady.trn  view on Meta::CPAN

presumably
Parcel(Nil) is a real returned Nil, whille Nil is no parcels
masak: nodnod
I said it just for you :)
okay, we're both lousy liars.
the next best thing to being zero...
only for continuous functions; fortunately, Heisenberg seems to have solve that for the physical world, so that physicists can cancel their dx's and dy's
*solved
rakudo: say True !and True
rakudo: say True !&& True
rakudo: say True !?& True
anyway, the ! metop is supposed to get you that already
*metaop
well, that's suboptimal :)
ng: say 1 !&& 1
we shouldn't generate on spec, mostly we should just do higher-order function calls
funny that % is considered iffy enough, but && isn't
no, | is supposed to snapshot the current CaptureCursor, so you can have params before that advance the cursor
I suppose we could allow params after too if | is considered a zero-width parameter
we have to have the ability to have multiple CaptureCursors anyway
in theory, CaptureCursors would make that trivial
and also enable the correct binding semantics for grep etc
where correct means "non-introspectively"
that's what Pm-19 was all about
though it's only an approximation
but basically we have a way of binding that the incoming cursor knows that it's a submatch, and returns a new cursor somehow
you can tell how many things were bound by comparing before/after on cursors
ruoso and I were discussing this the other day too
http://irclog.perlgeek.de/search.pl?channel=perl6&nick=&q=CaptureCursor
I should probably update Pm-19 with something in terms of CaptureCursor
what do you mean by 'grammar tool'?
um, what do you think it's doing now?
STD.pm already uses operator precedence to parse Perl 6
sure, but somewhere you have to have a bottom-up parser installed in your grammar that can make use of it
that's EXPR in STD
precedence is just annotations on subrules that function as a lexer
any bottom-up parser or parser-generator could examine those precedence annotations and do something reasonable with 'em
though a parser-generator isn't very flexible
which is why STD doesn't
it's currently set by <O()> assertions in the respective operator rules
usually by reference to a set of predefined precedence hashes defined earlier
ash__: and metaoperators either pass through the precedence of the base operator, or impose a new precedence of their own
most parser generators would have difficulty dealing with such dynamic precedence, which is why we stick with simple operator precedence.
and because parser generators tend to give lousy error messages
the default is addition prec, which is left associative
see also S06:1791
ash__: most of the operator definitions in STD don't actually belong there, and will eventually move to CORE
yes
CORE.setting has stubs in the current STD directory
mostly to declare known type names, currently
STD implements the setting as an outer lexical scope, though rakudo hasn't got there yet
colomon: um, spec tests shouldn't be using implementation dependent features such as pir::
colomon: that's fine, it just needs to go at some point
Str.succ is not intended to produce values in lexicographic order, which is relatively useless in real life.  So we steal .succ (and ++) for "counting with carry" in customary ranges
but see S03:431 and following
actually, that section implies that .succ is not used for ++ on strings, hmm...
that's specced, though
see S03:2029
why would you want to in increment kana?
it's not like the codepoints follow the a,i,u,e,o song...  :)
you can still use it as a Range, as in testing cmp its endpoints
but cmp has nothing to do with .succ, really
yes, and then if you do something non-sensical, you get a lot of nonsense :)
the test is supposed to be !after, which matches eqv
or the other way around
anyway, a direct hit is suppose to stop it
if you increment Z, yes
but not if you use 'after'
S03:2051 is talking about you, the Astute Reader
oh wait, my lines are off, hang on
that may take a while to propagate through
after it does, the irclog will link to the line in the spec
the log is at http://irclog.perlgeek.de/perl6/today
for the moment you'll have to back up a page to find the paragraph with "astute reader"
dinner &
you wanting hex?
looks like the S links have caught up with reality
LTA
setting
lexotic
phasers
unspace
feeds
sigspace, ratchet
captures, parcels
roles
junctions
shortnames/longnames
Christmas
but that's also Haskell
just like p5 list assignment
std: my $a; my @b; ($a, *@b) = <1 2 3>; say @b.perl
but it's an array
oh, wait, that's inside the french quotes
so yes
alpha is right
I was reading the [...] as OUTPUT delims
I'll learn this language someday...
party because [] used to be the OUTPUT delims, iirc
which is why we changed it
yeah, one dot is not enough to do that differently :)
though it's enough to do autoreversing
n8
but that won't work, since it uses 3 values
that is, 90, 100, 200 is going to confuse it
or maybe not, depend on whether the 2nd ... can actually see the earlier values
which in turn depends on whether it's right or left associative
and ... is defined as list associative, which doesn't help us :)
but it does mean we could probably force it to work with just 2 nums between the ...s
and you could force it the other way with parens
(1,2...9), 10, 20 ... 90  # second ... sees all lefthand numbers inluding 9
otoh, 9,10,20 is probably going to die if it can't intuit a function
I always like thos...
e
.oO(guess the next letter in the sequence...)
funny when a typo turns out self-referential
in the table, X operators are only right associative if the operator changes
otherwise it's like zip
dotdotdot(1,2; 10,20; 100,200; 900)
and the function can evaluate the lists however it sees fit
each of the sublists is independently lazy