pugs.blogs.com | pugscode.org | pugs.kwiki.org | paste: sial.org/pbot/perl6 | <stevan> Moose... it's the new Camel ":P | .pmc == PPI source filters! Set by Alias_ on 16 March 2006. |
|||
00:07
goedel joined
|
|||
TimToady | yay, now passing over 11,000 again. | 00:07 | |
wolverian | TimToady++ | 00:32 | |
TimToady | doubtless audreyt will find a way to drop that back down to a more reasonable number over the weekend. :) | 00:33 | |
00:35
meppl joined
00:36
Quell joined
|
|||
TimToady | I'm wondering whether we should disallow # as quote delims. | 00:48 | |
At least one of the tests fails because rx#/# eats the # trying to traverse the whitespace to find the delimiters... | 00:50 | ||
wolverian | what whitespace? :) | ||
TimToady | A comment is always whitespace... | 00:51 | |
wolverian | there is no comment there, is there? | ||
TimToady | there is if rx trys to traverse whiteSpace to get to the delimiter... | 00:52 | |
*tries | |||
whiteSpace = skipMany (simpleSpace <|> comment) | 00:56 | ||
00:56
Ymmv joined
|
|||
wolverian | what if there's only one whitespace? will skipMany ignore it? :) ah well. cough. | 00:58 | |
TimToady | If you'd like to rewrite the parser in P6 rules, that'd be cool. | 00:59 | |
I'm sure a lot of people would find [ <simple_space> | <comment> ]* a lot easier to understand... | 01:01 | ||
but it would still eat the #... | 01:02 | ||
meppl | gute nacht | 01:05 | |
01:09
oylenshpeegul joined
|
|||
TimToady | g'night | 01:09 | |
meppl | ;) | 01:10 | |
01:14
macroron joined
01:19
justatheory joined
01:24
rbysamppi joined
01:27
flounder99 joined
01:52
oylenshpeegul left
01:59
Khisanth joined
02:02
OutThere joined
02:03
OutThere is now known as SubStack
02:11
ayrnieu joined
02:13
stclare joined
02:22
macroron1 joined
02:43
integral joined
02:49
audreyt joined
|
|||
azuroth | anyone feel like drawing interaction diagrams? | 02:58 | |
03:07
frederico joined
03:33
aufrank joined
03:42
FurnaceBoy joined
04:00
FurnaceBoy_ joined
04:05
FurnaceBoy joined
|
|||
rbysamppi | Hey...in Synopsis 6, it talks about immutable and mutable types, then value and implementation types. What's the relationship between whether or not a type is mutable and if it's a value or implementation type? Could I do things like this: @something is Array; $input is IO; &pattern is Rule? | 04:41 | |
(All those variables are being declared.) | |||
PerlJam | you need a declarator in there somewhere. | 04:46 | |
rbysamppi | Yeah, I forgot them. | 04:50 | |
But assume that they're all my's. | 04:51 | ||
05:12
aufrank joined
|
|||
aufrank | hey all | 05:12 | |
PerlJam | though, I wonder if in absence of stricture, would "@foo is Array" create a package variable of the appropriate shape | 05:13 | |
I guess it must | 05:17 | ||
azuroth | foo bar baz quux quuux quuuux quuuuux | 05:18 | |
... | |||
FurnaceBoy | hey I know that tune. | 05:32 | |
06:09
ardder joined,
Quell joined
06:24
Aankhen`` joined
06:36
neoesque joined
06:38
penk left
06:58
ghenry joined
07:11
elmex joined
07:21
szbalint joined
07:28
iblechbot joined
07:52
Southen joined
|
|||
spinclad | Aragone: I don't see a way to keep parallel Judy1 + JudyHS arrays, since J1 takes word-length indexes and JHS takes counted strings | 07:53 | |
but it looks like adding first, next, last, prev to JudyHS would not be too hard, as long as you don't care about the order, only that it enumerates them all. | 07:55 | ||
08:08
KingDiamond joined
|
|||
spinclad | audreyt: see ^^ | 08:40 | |
at this point i'm ready to do four things: (1) add iterators to JudyHS and contribute them back, so we can use them for Hashes | 08:42 | ||
(2) build Tries with either Array[256] or JudyL[256] arrays | 08:44 | ||
(3) build the < %tokenclass | %tokenclass > tokenizer with Tries | 08:45 | ||
(4) do a precedence parser based on the rest of OPTable.pir | 08:47 | ||
i suppose the first thing to do is add these to -- what, not RT TODOs, that's parrot, right? just a TODO file somewhere. | 08:48 | ||
re (2), i'm thinking of stepping through the Trie by octets, but with JudyL array nodes one could reasonably step through by unicode chars (codepoints, i guess). | 08:52 | ||
09:03
larsen joined
09:18
pdcawley_ joined
09:29
nnunley joined
09:38
kanru joined
|
|||
Juerd | audreyt: /etc/sudoers updated | 10:16 | |
audreyt: /win 25 | |||
argh | |||
s[audreyt\: /win 25][] | 10:17 | ||
nnunley | /me hands Juerd a new set of fingers. | 10:19 | |
Heh. Irony. | |||
10:31
turrepurre joined,
KingDiamond joined
|
|||
Juerd | nnunley: I could use new wrists too. Do you happen to have some spares? | 10:33 | |
nnunley | I wish. | 10:34 | |
10:36
xerox joined
|
|||
nnunley | Hrm. So it looks 'fmap' has become deprecated. | 10:37 | |
10:54
DaGo joined
|
|||
gaal | nnunley: huh? | 11:09 | |
nnunley | Data.FunctorM is deprecated with ghc 6.5, and with it fmap. Not sure how long the deprecation cycle is in Haskell, though. | 11:19 | |
Err.. base-1.0, that is. | 11:20 | ||
Definitely doesn't hit pugs in the near future, but still. | 11:21 | ||
11:30
xerox joined
11:33
iblechbot joined
11:36
elmex joined
|
|||
gaal | that's... interesting. got a link to a discussion? | 11:39 | |
nnunley | www.haskell.org/ghc/dist/current/do...ctorM.html | 11:55 | |
gaal | hmm, so so many things will now have to derive Foldable... also, it seems that the Functor class and fmap aren't deprecated, themselves, just the monadic fmapM | 12:11 | |
curious to see that fold functions are now methods | 12:12 | ||
err no | |||
just limited to class | |||
err yes, actually, methods. | 12:13 | ||
12:14
pdcawley_ joined
12:19
trampel joined
13:49
DaGo joined
13:52
kanru joined,
Limbic_Region joined
13:54
neoesque joined
13:55
trampel left
14:08
lichtkind joined
14:17
miyagawa joined
14:25
justatheory joined
14:28
DaGo joined
14:35
pdcawley_ joined
|
|||
audreyt | spinclad: (enuming JHS) would be fantastic. | 14:42 | |
spinclad: write down any thoughts you may have w.r.t that and add it to docs/notes/? | 14:44 | ||
clkao | audreyt: good evening | 14:45 | |
audreyt | hi | ||
clkao | got mail about yaml::syck? | 14:46 | |
audreyt | yup | ||
clkao: sorry, was afk enjoying the latest cross-talk production in the series by Dr.Lai's Performance Workshop :) | 14:49 | ||
(the one after the "millenium crosstalk") | |||
audreyt resumes procmail'ing | 14:51 | ||
clkao | heh | 14:55 | |
audreyt | clkao: hm, YAML.pm and Y::Syck has inconsistent indent handling | 15:01 | |
clkao: what would you like me to do in the Y::Syck end? inhibit emission of double-quoted strings with indentation? imho it should be fixed at ingy's end | 15:05 | ||
clkao: YAML 1.1 spec section 4.5.1.1 shows that syck's treatment is canonical | 15:07 | ||
15:09
ushi joined
|
|||
clkao | i don't know, right now i can't switch bac kto use older svk because it uses yaml | 15:10 | |
audreyt | mm | 15:11 | |
15:11
larsen joined
|
|||
audreyt | inhbit emission of qq+newline will fix interop | 15:11 | |
but that is potentially expensive | |||
let ingy fix it at his end is perhaps easiest | 15:12 | ||
15:13
elmex joined
|
|||
clkao | mmm | 15:15 | |
aufrank | hi folks | ||
audreyt | aufrank: hey | 15:16 | |
what was the letter you wrote that TimToady mentioned? | |||
15:20
FurnaceBoy joined,
larsen_ joined
|
|||
aufrank | audreyt: I sent you two letters a couple of days ago | 15:21 | |
to audreyt at that name dot org | |||
one was asking for comments about a developer tools SoC proposal, the other about PDL on perl6 SoC proposal | |||
audreyt | ah. right. | 15:22 | |
oh, so you cc'ed tt on the 2nd one | |||
didn't noticed that. :) | |||
aufrank | yeah, he had been encouraging about that idea | ||
xerox | Did you find more pugs puppies to code Audrey? :-) | ||
(Howdy) | |||
audreyt | xerox: yeah, here is one with two ideas :) | 15:23 | |
xerox | Good! | ||
audreyt | I wonder if we are overflowing hs.org slots a bit, but then I don't see a "quota line" in hs.org's google page... | 15:24 | |
xerox | No, it's okay. | ||
We're thinking out how to make it fair, anyway :-) | |||
xerox unrolls the Mentoring Monad papyrus | 15:25 | ||
aufrank | audreyt: I'd still love to talk things out with you/ingy/juerd if any of you has time | ||
audreyt | the PDL (unified interface to vector/array/bitmap operations) one in particular probably belongs to hs.org more than perl.org if implemented on the Hs runcore | 15:26 | |
clkao | audreyt: so return value is through capture as well now? | ||
aufrank | yeah audreyt, I figured the developer tools would be a TPF proposal if anything, and the PDL would be haskell.org | 15:27 | |
audreyt | clkao: yeah. return is just invoking the return-cc "function" | ||
clkao: and it makes more sense to reuse callconv | |||
rather than conjuring another callconv out of thin air | |||
15:28
kanru joined
|
|||
audreyt | aufrank: the devtools one needs more... focus | 15:28 | |
I think "IDE support" is a clear banner | 15:29 | ||
so "vector data types"->hs.org and "IDE support"->pl.org? | 15:30 | ||
aufrank | that makes a lot of sense. I tried to bundle in some perl6 coding, but those aspects did make it seem very scattered | ||
yeah, that works for me | 15:31 | ||
audreyt | you aware of util/perl6.vim and util/cperl-mode.el ? | ||
15:31
larsen joined
|
|||
aufrank | yeah, but last time I tried those they weren't up to date with the spec | 15:32 | |
that said, the existence of those is one of the reasons I tried to think of other things to bundle into the proposal | |||
audreyt | I think for IDE support, perhaps the most critical one is an underlying library that editors can call to | 15:33 | |
which all revolves around the AST/Grammar | |||
that covers synhilight, taglookup, typeinfo, errmsgparse, and even rudimentary debugging | 15:34 | ||
it'd be nice if vim and emacs and eclipse and whatnot can use perl6 to parse perl6. | |||
(especially now that parsing perl6 without perl6 is going to be even more difficult...) | |||
aufrank | yeah, definitely | 15:35 | |
audreyt | and as such is easily 3mo proj | ||
aufrank | yup | ||
that sounds excellent | |||
audreyt | woot | ||
aufrank | I'm having trouble remembering what the name of the recent p5 pretty printing project was | 15:36 | |
parsing perl code according to a document model, IIRC | |||
there was at least one perl.com article on it | |||
audreyt | PPI. | 15:37 | |
aufrank | yeah, that's the one | ||
audreyt | Alias is occasionally here | ||
aufrank goes to look | |||
audreyt | and always on irc.perl.org #perl | ||
there is also TimToady's MAD | |||
now part of bleadperl | |||
that dumps op+doc tree as one xml tree | |||
so, the pdl one. Hs was traditionally very much _not_ a fast numerics language | 15:38 | ||
probably because people who need fortran knows where to find it | |||
aufrank | right | ||
there's at least one student interested in trying to make haskell friendlier to scientific computing this summer | 15:39 | ||
audreyt | oh? url? | ||
aufrank | I saw him in #haskell, but I'm checking now | ||
audreyt | but the fun of pdl is also that it makes things easier to script | 15:40 | |
there is a lot about this that can be learned from Guy Steele et al's Fortress | |||
it's quite p6-like (rather Scala-like) in many ways, but targetted at the scientific computing crowd | |||
15:43
mako132_ joined
|
|||
aufrank | audreyt: hackage.haskell.org/trac/summer-of-.../ticket/13 and hackage.haskell.org/trac/summer-of-.../ticket/24 are the proposals that are sort of related, but I don't think either of those is from the guy I saw on #haskell | 15:46 | |
audreyt: yeah, fortress is the language I'm most anticipating aside from p6 | 15:47 | ||
and they're not -Ofun at this point ;) | |||
audreyt | they are rather like Arc at this point ;) | 15:48 | |
xerox | But Arc isn't! :-) | ||
audreyt | (with all due respect to quux and pgraham) | ||
15:52
jsiracusa joined
|
|||
aufrank | bbiab, making some food & | 15:56 | |
TimToady | audreyt: did you see my earlier musings about outlawing # as a quote delimiter? | 16:02 | |
audreyt | TimToady: yeah. I don't see why not | 16:04 | |
I mean, we already disallow ws | |||
and # is arguably ws. | |||
TimToady | Just looking for simplifications... | ||
and since that's already what Pugs does... :) | |||
well, we're giving them most of Unicode plus [[[...]]], so I can't see that many complaints about losing #. | 16:05 | ||
16:05
Ymmv joined
|
|||
audreyt | yay :) | 16:06 | |
TimToady | also I was discussing virtualizing <%.foo|%.bar> earlier... | ||
and wondering about the performance implications. | |||
since we need to track the token sets along with the grammar mods... | 16:07 | ||
virtualizing just makes it a little harder to keep track of when to invalidate the cache, i guess... | 16:08 | ||
audreyt | ...and they are lexical to boot... | ||
TimToady | lexical to the comp unit, but dynamic to the cmpiler... | ||
audreyt | hm. | ||
TimToady | but you'd kind of like to think of each %.foo entry as its own method for overriding purposes... | ||
audreyt | currently I invalidate the cache after a BEGIN that may introduct new syms | 16:09 | |
regardless of what actually happened | |||
perf isn't great that way | |||
TimToady | which is likely suboptimal | ||
audreyt | indeed | ||
another thought is to make cache-invalid part of sym-table-entry-add | |||
TimToady | if we keep track of all the places it's used? | 16:10 | |
or make it check a valid bit that's in a handy place... | |||
audreyt | the latter is what I was thinking | ||
TimToady | I'm wondering if a more consistent symbol policy | 16:11 | |
like we did with my declarations | |||
would let us process macros more expeditiously. | |||
as in "you may not use a macro earlier than it defined in a lexical scope". | 16:12 | ||
theorbtwo | You can use macros retroactively? | ||
TimToady | no, but you can use macros from outside the current scope | ||
and then override them. | 16:13 | ||
that's what might be made erroneous in the interests of implementation. | |||
we basically already did that with my $foo | |||
basically, when we start a new lexical scope, it has a single new grammar, but we just don't know it all yet. | 16:14 | ||
that's the idea. not sure if it really works though. | |||
it probably won't fly. | 16:15 | ||
and stacked grammars in a single lexical scope can be useful. | |||
theorbtwo nods. | |||
TimToady | but we then do run into the same problem as with lexical vars, which is if a child calls back into our scope as its caller, which grammar do we tell them their statement was compiled with? | 16:16 | |
In particular, if that child is an eval. | 16:17 | ||
and wants to default to the same language it was called from. | |||
we need to be able to hand that child a $?PARSER that includes the macro names that were current at that point, however we define "current". | 16:19 | ||
that means that <%foo|%bar> can't be off in some other scope independent of the current parser object. | |||
that implies %foo and %bar are attributes of that parser object | 16:20 | ||
and written <%.foo|%.bar>. | |||
audreyt | uh. if it's in some scope, we can hand the child a closure. | 16:21 | |
i.e. close over %foo | |||
and hand it to that child | |||
even if %foo is a cache of some sort | |||
TimToady | It's a closure that has to persist from compile time to run time, is all. | 16:23 | |
audreyt | but we already do that for all BEGIN-time objects | ||
that's why we attach to the AST an "object space" | |||
with all compile-time-result objects | 16:24 | ||
and that applies to eval"" as well, yeah | |||
TimToady | yeah, I'm sure it's doable, it just needs to be efficient. | ||
16:24
justatheory joined
|
|||
TimToady | mostly efficient for subsequent compile in this block, not too worried about eval. | 16:24 | |
though in a sense they're the same thing. | 16:25 | ||
audreyt | well, they need to be the same thing | ||
otherwise we end up with perl5ish not-closing-over-enough-things eval"" | 16:26 | ||
which would be bad. | |||
TimToady | but my earlier talk of simpler policy is basically whether %.foo has to live in the current parser object or can live in COMPILING's lexical table. | 16:27 | |
audreyt | and I think it should be a lexical-table-pragma-thing | 16:28 | |
since its effect is as such | |||
TimToady | hmm, you mean use COMPILING %foo? | 16:29 | |
*<%foo> | |||
would have to be reimported on every subrule invocation | |||
since it could be a different parent grammar. | 16:30 | ||
audreyt | but a shallow lexical-pad-union thing is cheap | ||
TimToady | or do you just mean a policy to look up %foo in teh current $?PARSER? | ||
or the current COMPILING? | 16:31 | ||
audreyt | the current COMPILING. | ||
TimToady | (and all of its antecedents, for overlays) | ||
audreyt | (if this is slow, then OUTER is slow) | ||
TimToady | could just write the grammar <%COMPILING::statement_control|... | 16:32 | |
audreyt | that's what I mean, except perhaps %COMPILING::?GRAMMAR::statement_control | ||
or some other nonclashing names | |||
TimToady | this is basically just inside-out grammar objects... | 16:33 | |
seems a little silly, stated like that. | |||
audreyt | well, but if they are not closed over | ||
(which they are not usually) | 16:34 | ||
TimToady | they? | ||
audreyt | the %foo hashes | ||
they only get closed over when the block has an eval | |||
or equivalent | |||
inside it | |||
they are not "env", that is. | |||
TimToady | seems like it would be really easy to generate an awful lot of duplicate closures in parsing if we're not careful. | 16:36 | |
audreyt | (or exported, but that amounts to closing the scope over) | ||
and as such can be efficiently codegen'ed into a "local" register (to use parrotspeak) instead of a true lexpad entry, if we can make sure that a closure is not needed | |||
nod. | |||
but I thought it's the API here that you are wondering about... :) | |||
TimToady | I wonder about everything, except when I don't... | 16:37 | |
but yes, I'm mostly wondering what is the most natural API. | |||
and I do think that people can imagine a "current parser object" more easily than they can mysterious closures. | 16:38 | ||
audreyt | then in that case, <%COMPILING::foo> is I think not more strange than <%.foo> | ||
especially for people actually tweaking the p6 grammar | |||
i.e. I wonder why we are huffmanizing this :) | |||
TimToady | except for the fact that COMPILING has a policy of one-nameset per scope, and %.foo doesn't imply that | 16:39 | |
audreyt | yup. | ||
I guess I'm biased :) | 16:40 | ||
(mutable cursor properties vs. immutable closure-based updating) | |||
TimToady | well, as long as it always does everything everyone might ever want, I don't care. :) | 16:41 | |
audreyt | heh :) | 16:42 | |
TimToady | are you working on Capturizing pugs this weekend? | ||
(to the extent that anyone with ADD can be said to be "working on" any particular thing... :) | 16:44 | ||
audreyt | lol | ||
$job want me to port Jifty to Win32 | |||
already uncovered two XS module build failures so far | |||
XS and win32 doesn't easily mix it seems | |||
if I get them (and maybe more of them) resolved tomorrow, with the aid of the great CPAN community | |||
then yes, I'd love Capturizing pugs | |||
otherwise it'd have to wait till Monday. | 16:45 | ||
TimToady | k | ||
I'm just itching to start writing bits of the Pugs compiler in P6 rules... | |||
audreyt | oh, sure, but that's quite orthogonal to capturizing... | 16:46 | |
TimToady | but when we make the Capture <=> Match thing bridge across, we can start rewriting rules piecemeal. | ||
or start thinking about auto translation. | 16:47 | ||
audreyt | oh. right. | ||
nodnod. I've been thinking about autotranslation for months :) | |||
TimToady | I know. But I'd be happy with piecemeal hand translation. | ||
if only to prototype the autotranslator | 16:48 | ||
audreyt | nod. how about starting with Signatures? :) (Perl6::Subs, Perl6::Bindings, etc all have incomplete specs) | ||
and it'd equip Pugs with a good Signature parser; the current one doesn't do unpacking | |||
(any sort of) | |||
so is of limited use when writing tree transformers | |||
which relies heavily on unpacking | |||
TimToady | I can start thinking about that. | 16:49 | |
have my own set of distractions though... | |||
audreyt | :) | 16:52 | |
TimToady | speaking of which, I need to wander off. anything else hanging fire? | 16:53 | |
audreyt | not afaics | 16:57 | |
I envy that your distractions form a set | 16:58 | ||
mine is a cyclic graph with duplicate nodes | |||
(recursively defined) | |||
TimToady | at least such a thing can be lazily defined. | 16:59 | |
not sure it's sufficiently immutable though. :) | |||
Don't stay up past your bedtime, young lady! | 17:00 | ||
But also, Have the appropriate amount of fun! :) | |||
afk & | 17:01 | ||
audreyt | :) | 17:05 | |
aufrank | audreyt: the match object you get back from parsing a signature should have positional args in $/<positional>[0] or just $/[0]? | 17:08 | |
audreyt | I imagine $<positional>[0] would be more... descriptive | 17:09 | |
aufrank | so the match object after parsing a signature should have $/<positional>, $/<named>, and $/<returns> ? | 17:10 | |
audreyt | maybe... or maybe it needs to have several levels of invs | 17:11 | |
aufrank | and we'd want something like $/<named><foo> to also have a <type> match for sub bar ( $foo ::Dog ) {...} | ||
invs? | |||
audreyt | sub foo ($x : $y : $z : $w) | 17:12 | |
tiebreakers | |||
aufrank | I'm not parsing the single colon there | ||
audreyt | mm? | 17:16 | |
but it's tiebreaking | |||
conceptually we have tiebreak, pos, nam, slurpy "zones" | |||
aufrank | I meant my human brain does not recognize what that syntax would mean in a sub =\ | ||
audreyt | oh oh ok | ||
sorry. it only makes sense in a multi | 17:17 | ||
multi foo (Int $x : Str $y : Num $z) {} | |||
aufrank | oh oh, ok | ||
so those are each potential invocants? | |||
that's what you meant by invs | |||
aufrank clicks | |||
audreyt | in multi there may be multiple such tiebreaking levels | 17:18 | |
aufrank | ok | ||
audreyt | multi foo ($x, $y : $z, $w : $a) | ||
currently they should all be positionals | |||
(but it's a bit silly) | |||
aufrank | and each tie breaking level can have positionals, nameds, and slurpy zones? | ||
audreyt | no, slurpy can't be | 17:19 | |
aufrank | (but not implicit paramaters) | ||
audreyt | nameds aren't required to be there in 6.0.0 | ||
aufrank | ok | ||
audreyt | so essentially just multi-level of tiebreakers | ||
then the final non-tiebreaking level | |||
consisting of pos, named, and slurpy | |||
aufrank | got it | ||
aufrank updates his notes | 17:20 | ||
audreyt | but, each positional also has a name | ||
aufrank | yeah, I saw that in the test | ||
audreyt | and in fact can have a different internal name from an external name | ||
aufrank | also, the name of the argument doesn't necessarily match the internal name of the variable | ||
audreyt | sub foo (:external($internal)) {} | ||
aufrank | right, but that is a named, not a positional, right? | 17:21 | |
audreyt | right. | ||
positionals always assume the same name | |||
aufrank | the only way to treat a positional as a named is to use its internal name as its external | ||
audreyt | (which may or may not be a bug) | ||
aufrank | right | ||
audreyt ponders | |||
sub foo (:x($y) is positional) | |||
but no, it's not part of spec | 17:22 | ||
according to spec, yes. | |||
aufrank | so all args matches have a slot for type constraints, external name, and internal name | ||
the last two can be different for nameds, but are always the same for pos's | 17:23 | ||
audreyt | aufrank: look at src/Pugs/AST/Internals.hs | ||
line 799 | |||
the various boolean traits can be merged into a single "traits" Set | 17:24 | ||
other fields need special treatment | |||
namely, "default", "name", and "context" | 17:25 | ||
aufrank | seeing it :) | ||
audreyt | and now we have external name as well. | ||
also, that does not cover unpacking | |||
which would need another slot per-param | |||
to hang another Signature into a param | |||
to allow subcasing | |||
aufrank | right, a code parameter with its own :(...) sig | ||
audreyt | as wellas | 17:26 | |
sub f (@array [$head, @*tail]) {} | |||
or | 17:27 | ||
sub register ({:$name, :$addr, *%guest_data}, $room_num) { | |||
} | |||
in the latter case we have an anonymous (empty named) positional | |||
which is then unpacked-as-hash | |||
aufrank | right | ||
audreyt | so the unpacking has three forms: as-hash, as-array, and as-signature | 17:28 | |
but the unpacking param all take just the Sig | |||
so it's just a flag on the unpacker | |||
or even better, just reuse the same "sigil" flag: hash/array/scalar | |||
but that's all BDUF | 17:29 | ||
make something work first == more fun :) | |||
aufrank | if I manage a checkin, where should it live? | ||
audreyt | maybe src/Pugs/Parser/Signature.pg | 17:30 | |
to faciliate scw's .pg.hs translator later | 17:31 | ||
aufrank | ok, I'm gonna keep working on it :) | 17:33 | |
audreyt | :) | 17:35 | |
g'nite | |||
17:42
rbysamppi joined
18:02
mako132_ joined
18:06
r0nny joined
18:24
Quell joined
|
|||
theorbtwo thinks length('audreyt') == length('aufrank') and substr('audreyt', 0, 2) eq substr('aufrank', 0, 2) makes me confused. | 18:29 | ||
18:30
sockstat joined
|
|||
aufrank | theorbtwo: I was the only au.* I knew for a long time | 18:33 | |
everyone in my office signed their mails "/" ~ substr($name,0,1) | 18:34 | ||
and there was already an alan who had dibs on /a | |||
theorbtwo | Yeah, Castaway and Corion joined perlmonks around the same time, and both just signed "c", only in different cases. | 18:35 | |
aufrank | so I was /au and usernames and email addys followed from there | ||
aufrank hasn't been around the monastery in a while | |||
18:37
solarbunny joined
|
|||
FurnaceBoy notices the same confusion as theorbtwo and wishes this irc client would auto-colour code people | 19:00 | ||
FurnaceBoy never really investigated whether it will, just thinks it would be useful | |||
19:06
penk joined
19:11
elmex_ joined
19:18
ruoso joined
19:19
mako132_ joined
20:01
lichtkind joined
|
|||
lichtkind | i got to my birthday an t-shirt with an larry wall photo and the slogan "to perl or not to perl that is here the kvetchion", fortunatly didnt had the tshirt shop chartreuse | 20:27 | |
theorbtwo | fortunately the t-shirt shop didn't have chartreuse" | 20:28 | |
Er, '"'.$last | |||
lichtkind | sorry i dont understand | 20:29 | |
szbalint | haha | ||
20:29
frederico joined
|
|||
theorbtwo | I was trying to correct your grammar. | 20:30 | |
szbalint | nice bday present. | ||
lichtkind | ok thanks thats always help | ||
20:31
FurnaceBoy is now known as FB|afk
|
|||
theorbtwo | And, naturally, couldn't manage to get my own quite right. | 20:31 | |
lichtkind | yes i slowly i got famous in promoting perl :) | ||
20:41
eal left
20:47
KingDiamond joined
20:56
interferon joined
20:57
interferon left
|
|||
nothingmuch | what would you name the property "knows where it is in a tree" or somesuch | 21:05 | |
wolverian | a type? :) | 21:06 | |
nothingmuch | ? | ||
oh | |||
no, it's a role | |||
i mean, what would you name the role/typeclass | |||
that implies that you can ask a node who it's parent is | |||
wolverian | node? | 21:09 | |
nothingmuch | nope, that's taken, and it doesn't necessarily know who it's parent is | 21:10 | |
wolverian | child? | 21:11 | |
("its", btw) | |||
nothingmuch | yeah, sorry, it's =) | ||
i was thinking ChildOf maybe | |||
since that's a bit more explicit | |||
but... meh | |||
there must be a more compsci-savvy name | |||
wolverian | w3c uses child :) | ||
TimToady | pedigree maybe? | 21:12 | |
nothingmuch | wolverian: it can be child without knowing who it's parent is | ||
oof, phone =/ | |||
wolverian | nothingmuch, adopted? :) | 21:13 | |
NotOrphan | |||
nothingmuch | oof | 21:18 | |
i hate jewish mother syndrome | |||
wolverian | heh, what? | ||
nothingmuch | a good friend of mine, who does that a lot, just phoned me up | ||
her boyfriend dumped her | 21:19 | ||
so she called herself an idiot for even trying | |||
and yadda yadda yadda | |||
now, if you don't comment, you're insensitive | |||
if you agree, you're calling her an idiot | |||
if you disagree you're violating her space because she's hurt | |||
21:19
FB|afk is now known as FurnaceBoy
|
|||
nothingmuch | when people do that to me i try to be mean (== honest) | 21:20 | |
usually they realize i'm not going to fall for that | |||
and try something else | |||
but this time it was pretty tough | |||
i think i'll just go with HasParent | |||
wolverian | ?eval (1..10) ~~ 2.5 | 21:26 | |
ruoso making pizzas | 21:27 | ||
wolverian | ENOEVALBOT :( | 21:28 | |
21:32
shachaf joined
|
|||
spinclad | i dunno, i think you could pass on commenting on 'idiot' and go with 'yeah, that sucks' and so on | 21:36 | |
but there's lots of ways to play the game | 21:38 | ||
nothingmuch | spinclad: the point is to delegate bad feelings | 21:55 | |
she feels like shit | |||
she wants me to feel like shit | |||
i'm willing to be empathic | |||
even sympathetic to a certain degree | 21:56 | ||
but i will not feel bad just because she does | |||
22:13
elmex joined
|
|||
theorbtwo | .oO(Dropping like flies.) |
22:13 | |
Juerd | Als achter vliegen vliegen vliegen, vliegen vliegen vliegen achterna | 22:16 | |
Odin-LAP | Juerd: Tongue twisters? | 22:41 | |
22:44
macroron__ joined
22:53
SamB joined
|
|||
wolverian | hrm, why is <> the same as $*ARGS? how is $*ARGS related to STDIN? | 23:05 | |
theorbtwo | wolverian: Something like how <>, <ARGV>, and @ARGV are related in p5. | 23:06 | |
wolverian | theorbtwo, I have never understood why <ARGV> reads from STDIN. | 23:09 | |
merlyn | in perl5? | 23:10 | |
wolverian | (I mean, it is convenient to have something that does so, but why is it called 'ARGV'?) | ||
merlyn, yes. | |||
merlyn | only if @ARGV is empty or contains "-" | ||
if @ARGV is empty when <> is invoked, then "-" gets shoved into it | |||
so really, it's only when "-" is seen | |||
wolverian | ah. | ||
merlyn++ | 23:11 | ||
merlyn | and then $ARGV = "-" | ||
wolverian | now it makes sense. it's invisible magic. | ||
merlyn | not entirely invisible | ||
you can see @ARGV being nibbled, and $ARGV being set | |||
theorbtwo | (Except, of course, @ARGV doesn't appear to contain '-', so it's not quite that magical.) | ||
merlyn | well - it wouldn't at the time | ||
theorbtwo | Er, it's not quite that magic. It's even more magical. | ||
merlyn | it's an indivisible step | ||
if <> needs to open a file, and @ARGV is empty, then @ARGV = "-" | 23:12 | ||
$ARGV = shift @ARGV; open ARGV; | |||
etc | |||
so it's in @ARGV for a moment. :) | |||
but you don't have access at that moment | |||
theorbtwo | Makes sense. | 23:13 | |
merlyn | and you *can* put "-" in @ARGV | ||
"this", "-", "that" | |||
theorbtwo | Somewhat more obnixiously, you can put "|foo" into @ARGV, and perl will happily run your program. | ||
merlyn | that's a *feature* :) | ||
theorbtwo | Indeed. | 23:14 | |
merlyn | although most coders would be surprised by that. | ||
23:15
Limbic_Region joined
|
|||
wolverian | is there a short syntax to temporize an object's attribute? something like i.e. my $foo = $*ARGS.with(irs => undef).readlines; # although I know .slurp would work too | 23:25 | |
s/i.e.// # redundant | 23:26 | ||
23:38
trym joined
|
|||
Juerd | Odin-LAP: No, Dutch people are used to such tongue exercise. | 23:41 | |
23:47
Limbic_Region joined
23:48
kanru joined
23:49
mako132_ joined
23:58
trym joined
|