Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6, 2007-05-05

Perl 6 | Reference Documentation | Rakudo

| Channels | #perl6 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:01 awwaiid joined #perl6
00:02 Khisanth joined #perl6
00:13 dduncan ?eval sub foo (Int $x --> Str) {...};
00:13 evalbot_r16189 changed the nick to evalbot_r16187
00:13 evalbot_r16189 undef
00:13 dduncan ?eval sub bar (--> Str) {...};
00:13 evalbot_r16189 Error: ␤Unexpected "-->"␤expecting formal parameter or ")"
00:13 dduncan now, having routines without arguments is common, and I would have expected the second to work
00:14 pasteling "TimToady" at 71.139.27.123 pasted "Anyone recognize this build failure (ghc-6.6 from FC6 extras)" (424 lines, 27.5K) at http://sial.org/pbot/24691
00:15 dduncan but even if it worked, I think I'll stay with 'of' in the short term, or alternately go with the sub Foo bar () {} form
00:15 dduncan that is, however, if <-- could be made to work in signatures, I would then prefer that, probably
00:15 TimToady no, Foo has to come before sub
00:16 dduncan right, Foo sub bar
00:16 TimToady which means you need a declarator before that: "my Foo sub bar"
00:16 TimToady though maybe we can relax that eventually
00:16 dduncan hm, perhaps I'll just leave the 'of'  as is for now, since it already seems to work
00:17 dduncan or at least it doesn't cause a failure
00:17 TimToady the (--> is a known bug.  the "cheat" translates it it ( *%_ -->
00:17 dduncan still, if <-- isn't in the spec yet, could it reasonably be made to work?
00:17 dduncan that is, put in the spec?
00:18 PerlJam dduncan: made to work how exactly?
00:18 TimToady generally you want the return type on the right if you're going to define it in terms of types on the left
00:18 TimToady you can't use T retroactively in a sig
00:19 dduncan I think the parity would be nice, as we have parity with feed operators <== and ==>
00:19 PerlJam TimToady: But I read right to left!  ;-)
00:19 TimToady you're PerlJam, not Perl
00:19 dduncan it seems to me that having the choice of params --> return or return <-- params would be nice
00:19 TimToady next you'll be wanting <-
00:20 dduncan I wouldn't consider that to be the same situation
00:20 TimToady I don't consider <-- to be the same situation as <==
00:21 PerlJam dduncan: beware the hobgoblin of foolish symmetry  :)
00:21 PerlJam Though I have to admit that --> does seem like a syntactic oddity compared to the rest of the language (to me anyway)
00:21 dduncan more generally, my preference if it is reasonable is to have the return type appear first in a signature, some how ... it doesn't have to be marked with <-- ... if necessary, I may just use the existing my Foo sub or sub bar of Foo forms
00:22 dduncan I just thought making it look like <-- would be more intuitive if people already know -->
00:22 avar TimToady: How does the implicit $/ lexical "happen" after regex matches as it were? Macro in the compiler?
00:23 avar that's probably more implementorish:)
00:23 TimToady doesn't "happen" after the regex, except for binding to the existing $/
00:23 TimToady the regex knows the $/ it's supposed to bind the result to
00:24 TimToady but the $/ variable is declared from the top, like $_
00:24 japhb dduncan: having the return type first always seemed a little wrong-endian to me.  When I'm looking up a function's signature, I'm more caring what the arguments are than what exact type it returns, since most of the time I just want Scalar (Item?) return anyway
00:24 amnesiac joined #perl6
00:25 dduncan I find having the return type first makes it closer to what actually uses it or what it describes in typical situations
00:25 TimToady 'course, you can argue that if you do want to specify a return type, it's exceptional, and should be in front
00:25 japhb TimToady: I forget, did you decide to differentiate multi by return type as well, or only args?
00:25 TimToady but in that case, bring it all the way out front
00:25 japhb TimToady: exactly
00:26 PerlJam Hmm.
00:26 japhb Besides, I think the argument that return type is notionally part of the signature makes a lot of sense, so I expect to have it inside the parens
00:26 dduncan I think the return type is just as much part of a signature as its parameters
00:27 japhb ... and when inside the parens, it should be last to me.
00:27 TimToady the of type is, but not the "returns" type
00:27 dduncan I refer to the 'of' type
00:28 japhb Because as my eye scans left to right, using (Type <-- args) I have to backtrack my brain at <-- to realize that the type was not going to refer to an arg's type.  I don't want to have to mentally backtrack.
00:28 dduncan having it part of the signature assists systems that want to do strong typing, and it is easier to determine at compile time if where you use the result of a routine is type compatible with what the routine returns
00:28 dduncan eg, wants_Int( returns_Int() )
00:29 TimToady sure, but we currently call that the "of" type
00:29 japhb I like the reduced backtracking of the Perl 6 grammar for mental reasons more even than for compile time efficiency
00:30 dduncan yes
00:30 TimToady if you declare a "returns Int" it is explicity not part of the sig
00:30 dduncan true, I should say that as wants_Int_param( of_Int() )
00:30 TimToady it's just an implicit coercion on all your return statements
00:30 dduncan I mean, has_Int_param
00:30 dduncan or wants_Int_arg
00:31 dduncan speaking generally, I like to use the strong typing features
00:31 dduncan things that let us move work to compile time from run time
00:33 japhb TimToady: I (think I) understand the difference between 'of' type and 'return' type, but the name is very confusing.  It will end up being a FAQ as much because the naming is counter to other language use than because it is intrinsically difficult conceptually
00:34 TimToady could well be
00:34 TimToady maybe it's an "as" type or some such
00:34 dduncan I suggest renaming 'return' to 'coerce' or some such
00:34 dduncan the 'of' is fine
00:34 TimToady on return types for tiebreaking, this is discussed in S12:899
00:36 japhb Actually, I think changing returns to as sounds nice.  Because 'as' says coerce, while being short and clearer to the common man
00:36 dduncan yes, that should work
00:36 dduncan 'returns' to 'as'
00:36 dduncan and leave 'of' as is
00:37 japhb exactly
00:38 japhb The other problem with the word 'returns' is that it is ambiguous; it's unclear if it is a coersion, a constraint, an assertion ....
00:38 dduncan that said, unless this matter is already covered somehow, perhaps 'as' could also be used for parameters, to indicate whether you want them to accept arguments coerced to that type versus arguments that are already of that type without needing to be coerced
00:38 japhb Oh now that's interesting ...
00:39 dduncan for example, I want to be able to say that I want a Bool argument, not just anything which can do Bool, which is everything
00:39 dduncan so then that argument will only ever get Bool::False or Bool::True
00:40 japhb So you have the cases '$arg', 'Foo $arg', and '$arg as Foo', handling the cases: no change, require Foo, and coerce to Foo
00:40 Khisanth joined #perl6
00:40 dduncan yes, along those lines
00:40 japhb I like it
00:41 dduncan though for parity with routine return/of types, the second could be spelled either 'Foo $arg' or '$arg of Foo'
00:41 PerlJam FWIW, I like it too.
00:41 * japhb feels a big 'as' normalization coming on ...  :-)
00:41 PerlJam Though the shortness of "as" and "of" bother me a little bit.
00:42 PerlJam (as far as differentiating the two)
00:42 dduncan I would think they are used a lot, so good huffmanizing
00:42 japhb I'm not delighted with 'of', but I'm not confused by it.  'returns' causes cognitive dissonance and confusion.
00:42 dduncan sure, they are both short, but they visually look quite different
00:42 dduncan as does either from "is"
00:42 japhb And 'as' gets nice and useful for any place we want a coerce done for us declaratively
00:42 japhb As dduncan showed
00:45 dduncan TimToady, any thoughts on that, being able to declare params allowing coersion vs those that require none, or don't care, as we have with return/of ?
00:45 dduncan this said, I'm thinking that certain matters related to the meaning of .does() may be impacted by this
00:46 japhb dduncan: how so?
00:46 dduncan for example ...
00:47 dduncan say we want to specify Bool without coersion, because we want the only values given to us to be values part of the Bool type, which are Bool::True and Bool::False, but afaik, anything that can do Bool could have many other values than that, eg zero or empty string for false, practically anything for true
00:48 dduncan to specify Bool without coersion, I could then be saying I want to use === to compare an argument with a literal Bool value, and have it work
00:48 japhb If we only want to get Bool::True and Bool::False, we *do* want to coerce.
00:49 japhb If you really, really only want Bool, and not something that .does Bool, you need to coerce.
00:49 scsibug changed the nick to scsibug``
00:49 dduncan eg, "if $bool === Bool::True" should work
00:49 scsibug left #perl6
00:49 dduncan one moment ...
00:50 dduncan I'm thinking it is useful to differentiate between subtypes of a type and an object that can do that type
00:51 TimToady sub foo (::T $b where T === Bool)
00:51 dduncan eg, a routine wanting an Int without coersion would accept an Int, a PosInt, an EvenInt etc, but not accept a Str that looks like a number
00:51 japhb TimToady: that syntax makes some sense, but it's ugly
00:51 TimToady maybe it's ugly on purpose
00:52 japhb And it's still not clear if that is a hard constraint or a coersion without looking at the spec
00:52 dduncan I like strong determinism ...
00:52 TimToady unnecessarily restricting your arg types is construed as bad polymorphism, generally
00:52 TimToady no, you just think you like strong determinism.  :)
00:53 japhb TimToady: I agree, but I can see good reasons for needing it available.
00:53 TimToady and ugly. :)
00:53 dduncan eg, if I make a unary function whose of-type is Int and it takes an Int, and the function is a 1:1 map, I would prefer that only one possible value could be given as an argument for each possible output
00:54 japhb TimToady: still, what do you think of s/returns/as/ and allowing '$arg as Foo' to coerce?  Or is that already done, and we just missed it
00:54 dduncan so, eg, if f() and g() are inverse functions in that 1:1 map, then for any $x, f(g($x)) === $x is guaranteed to work, assuming $x is the correct type
00:54 TimToady ?eval 1 as Num
00:54 evalbot_r16189 Error: ␤Unexpected "as"␤expecting operator
00:54 TimToady ?eval Num(1)
00:54 evalbot_r16189 Error: No such subroutine: &Num
00:57 dduncan but if, say, different strings like "42" and " 42 " can both be coerced to the integer 42, then Str $x = ...; stringify(numify($x)) === $x won't always return true if $x is interpretable as a number
00:57 TimToady dduncan: most Perl programmers would find such semantics abhorent
00:58 dduncan well, fair enough if some users want things less deterministic, but I like the option to be more deterministic
00:58 dduncan "more than one way" and all that
00:58 PerlJam perl isn't just for perl programmers is it?  
00:58 dduncan unless you think providing the option just causes a lot of trouble?
00:59 japhb TimToady: were you showing what the syntax would be, but it's not implemented, or ... ?
00:59 TimToady all is fair if you predeclare
00:59 japhb (for as)
00:59 TimToady there used to be an "as" operator, but I think we deleted it in favor of Foo($x)
00:59 TimToady ?eval 1.Num
01:00 evalbot_r16189 Error: No such method in class Int: &Num
01:00 TimToady but that isn't implmented
01:00 TimToady ?eval 1.as(Num)
01:00 evalbot_r16189 Error: No such method in class Int: &as
01:00 dduncan personally, I think Num(1) does look better than 1.as(Num0
01:00 dduncan s/0/)/
01:01 japhb So how would that look in a signature, compared to non-coercing type?  (Foo($arg)) v. (Foo $arg) ?  That's a little too close.
01:01 TimToady ::T $arg where T === Foo doesn't look the same
01:02 japhb OK, perhaps I'm not understanding the latter syntax ... I thought the where version was a constraint, not a coersion?
01:03 japhb In the same way that subtypes constrain the set of possible values, rather than trying to coerce an Int to an Odd
01:03 TimToady Foo $arg can be coercing if Foo is defined that way, but that's the default only for Int/Num/Str types
01:04 dduncan all this said, regardless of whether we get coersion or not on the user side, I would hope that within a routine, if I have an parameter Int $foo, and later do eg "$foo", then that string will only contain a canonical stringification of $foo, and not whatever string it actually was if $foo was passed a string
01:04 japhb I think dduncan and I have different use cases in mind.  I just want to declare coersions in the signature that I'm going to make anyway, rather than buried in the routine's code somewhere.
01:05 PerlJam japhb: including inheritance coercions?
01:05 japhb Having Int/Num/Str coerce by default, and no other type coerce by default, has a design odor to me.
01:06 dduncan I'm not asking for different types to be treated differently
01:06 TimToady not really; they're that way because they define themselves appropriately
01:06 japhb PerlJam: why not?
01:07 PerlJam japhb: hmm. now it sounds real easy to paint yourself into a corner
01:07 japhb TimToady: I meant, if coersion is off by default, but all the builtin types explicitly turn it on, then perhaps the default is wrong ... or the reason they all want to coerce needs to be examined.
01:07 * japhb doesn't feel like he's communicating well today
01:08 dduncan what I would like is that if, for example, I convert any non-Str type to a Str using some implicit method like "$foo", then the result will be canonical for the type I thought I asked for ... eg, if $foo was a parameter of type Int, I would expect "$foo" to look the same as if an actual Int was passed as an argument to $foo
01:09 japhb PerlJam: No argument there ... but I want enough rope to hang myself.  In particular, I want to declare, in one obvious place, whether I intend to make use of .does semantics on a type, or force a coersion.  Maybe I'm just weird like that.
01:09 dduncan so eg, if " 42 " is passed to Int $foo, and I say "$foo", I want the spaces to be gone
01:09 dduncan that's actually the main importance
01:10 japhb dduncan: to you, perhaps.  :-)
01:10 dduncan in that case, I do actually want the argument coerced to an Int, and not left unchanged just because it already does Int ...
01:11 dduncan or maybe that is a non-issue
01:11 dduncan ...
01:11 japhb One of my use cases: I want to be able to "strip some magic off" of an argument passed to me, before handing it off to another routine that would handle the magic wrongly
01:12 dduncan makes sense
01:13 dduncan actually, this also is one of my concerns ...
01:13 japhb For example, let's say I have an object that stringifies to something different than the string version of what it numifies to.  I would like to be able to hand that off to something that writes the numified form to disk.  How do I tell it I want the string version of the numification, rather than the default stringification?
01:14 japhb Currently, I can create a new Num, assign my magic object to it, and hand it off, no problem ...
01:15 japhb except sometimes I might want to *declare* that that is what is going to happen, rather than doing it in the return body where it may not be noticed, or may be done on some code paths and not others
01:15 japhb DRY and be transparent
01:15 dduncan here is one thing I want to be able to do; if I declare eg, my Seq $foo, then I don't want an Array being assigned to it just because Array does Seq, since I want to count on the container $foo points to not being mutable
01:16 dduncan if I have a Seq parameter, and someone assigns an array, I want that converted to a Seq before I get it, so I can keep that value around, eg as an attribute, and count on it not to be modified indirectly by external code
01:16 dduncan s/assigns an array/passes an array arg/
01:17 * japhb thinks 'my $foo as Seq' meaning 'Coerce to a Seq anything assigned in'
01:18 dduncan so when it comes down to it, I am okay with Perl coercing arguments, I just want to know that what I received has all the semantics of the parameter type, including immutability
01:18 dduncan this matter is fundamental, actually, since a type could do Str or Int etc, which while the latter are immutable, the other type may not be
01:19 dduncan I want to be able to count on things not changing on me ... that's important
01:19 dduncan only if I explicitly declare a mutable type for a param type, eg asking for an Array, should I expect that it might mutate
01:19 japhb But isn't that what 'is copy' is for?
01:20 Aankhen`` sub foo (Bar $baz is exact)?
01:20 TimToady that makes it mutable
01:20 TimToady or makes it look mutable, anyway
01:20 TimToady Bar! $baz
01:20 dduncan is copy is for when you know you're getting a mutable type, and you want to change it yourself without it changing for the caller, afaik
01:20 TimToady but might be confused with Bar $baz!
01:20 dduncan in that respect, is copy should have no effect on an immutable typed param/arg
01:21 japhb I kinda like Bar! $baz.
01:21 Aankhen`` Maybe make people uppercase the type name if they want only that type. <G>
01:21 dduncan makes no sense when names are case-sensitive
01:21 japhb BAR_NO_REALLY_I_MEAN_IT $baz
01:21 Aankhen`` japhb: Exactly!
01:22 * Aankhen`` points dduncan at the <G>.
01:22 dduncan I've been called to dinner, but will backlog ...
01:22 TimToady dduncan as Diner
01:22 * japhb imagines dduncan in bright silver with a neon sign on his head
01:23 japhb English ... because it's fun.
01:25 japhb TimToady: are gears turning in your head, or are we just insane?
01:25 TimToady the two are not mutually exclusive
01:25 japhb (mmmm, tasty false dichotomy)
01:28 TimToady I can see arguments for Foo $x as Bar, but the common case is perhaps Foo $x as Foo
01:28 japhb seek_food & # Something that tastes very umami
01:28 TimToady which Foo! $x might be short for
01:28 TimToady mushrooms work
01:29 TimToady on the assumption that $x as Foo means Any $x as Foo
01:31 rhr mushrooms work on me without any assumptions :)
01:41 pasteling "rhr" at 65.94.38.10 pasted "proposal for IO/feed interactions" (16 lines, 499B) at http://sial.org/pbot/24693
01:45 avar I remember that using sbcl came up in early parrot runtimes but not what was said, is there any reason for why the existing common lisp runtimes might not be able to run perl6 ?
01:48 avar nm:) sleep&
01:56 kanru joined #perl6
02:10 Khisanth joined #perl6
02:14 spinclad ?eval ~+' 42 '
02:14 evalbot_r16189 "42"
02:15 kanru joined #perl6
02:22 kanru joined #perl6
02:23 dduncan and I'm back
02:30 kanru joined #perl6
02:46 yves_ joined #perl6
02:51 kanru joined #perl6
02:52 obvio171 joined #perl6
03:03 elmex_ joined #perl6
03:10 REPLeffect joined #perl6
03:17 justatheory joined #perl6
03:37 goban joined #perl6
03:46 kunwon1 joined #perl6
03:47 SubStack joined #perl6
04:05 fayland joined #perl6
04:27 obvio171 joined #perl6
05:21 rashakil joined #perl6
05:40 dolmans joined #perl6
06:09 obvio171 joined #perl6
06:15 [particle] joined #perl6
06:15 svnbot6 r16190 | Darren_Duncan++ | ext/QDRDBMS/ : added some methods to AST.pm
06:20 zzz_reaper left #perl6
06:23 dduncan left #perl6
06:26 gnuvince_ joined #perl6
06:30 justatheory joined #perl6
06:34 sunnavy joined #perl6
07:01 obvio171 joined #perl6
07:23 jisom joined #perl6
07:30 torz joined #perl6
07:31 BooK joined #perl6
07:43 source_guy joined #perl6
07:45 demq joined #perl6
07:58 source_guy left #perl6
08:41 ozo joined #perl6
08:45 ozo_ joined #perl6
08:51 obvio171 joined #perl6
08:57 obvio171 joined #perl6
08:58 iblechbot joined #perl6
09:00 REPLeffect joined #perl6
09:01 obvio171 joined #perl6
09:06 obvio171 joined #perl6
09:12 obvio171 joined #perl6
09:13 rindolf joined #perl6
09:14 ozo__ joined #perl6
09:15 obvio171_ joined #perl6
09:18 ingy hola
09:20 rindolf Hi ingy
09:20 rindolf ingy: what's up? How do you feel?
09:21 ingy i feel pain in my arm
09:21 ingy and happiness in my heart
09:22 rindolf ingy: that's good, well at least except from the pain in your arm.
09:23 ingy i have an idea of how to use 'warnings' and 'our' in 5.5
09:23 rindolf ingy: why do you need perl 5.005?
09:24 ingy rewriting YAML.pm
09:24 ingy people will be pissed if I require 5.8.3
09:24 ingy :)
09:25 ingy which I usually do now
09:25 franck__ joined #perl6
09:25 Tene What's the typical situation where people require an old perl but the latest YAML.pm?
09:26 ingy beats me
09:28 ingy YAML::Syck  supports 5.3.7!
09:28 larsen_ joined #perl6
09:50 rindolf Hmmm... File::HomeDir is broken.
09:57 rindolf ingy: I think you should aim for perl-5.6.2
09:57 rindolf ingy: perl 5.005 is an absolute brain-damage.
09:59 ingy rindolf: 5.8.0 is horrendous
09:59 ingy :)
09:59 rindolf ingy: yes, that too.
09:59 rindolf ingy: VMware ESX still ships with it.
09:59 rindolf And so do many other RHELs.
09:59 ingy !
10:04 sreejesh joined #perl6
10:09 buetow joined #perl6
10:10 obvio171_ joined #perl6
10:14 larsen_ joined #perl6
10:14 BooK joined #perl6
10:14 jisom joined #perl6
10:14 rashakil joined #perl6
10:14 goban joined #perl6
10:14 yves_ joined #perl6
10:14 amnesiac joined #perl6
10:14 awwaiid joined #perl6
10:14 mr_ank joined #perl6
10:14 lumi joined #perl6
10:14 charsbar joined #perl6
10:14 autark joined #perl6
10:14 electrogeek joined #perl6
10:42 larsen_ joined #perl6
10:42 BooK joined #perl6
10:42 jisom joined #perl6
10:42 rashakil joined #perl6
10:42 goban joined #perl6
10:42 yves_ joined #perl6
10:42 amnesiac joined #perl6
10:42 awwaiid joined #perl6
10:42 mr_ank joined #perl6
10:42 lumi joined #perl6
10:42 charsbar joined #perl6
10:42 autark joined #perl6
10:42 electrogeek joined #perl6
10:43 riffraff joined #perl6
10:44 chris2 joined #perl6
10:59 elmex joined #perl6
11:00 larsen_ joined #perl6
11:00 BooK joined #perl6
11:00 jisom joined #perl6
11:00 rashakil joined #perl6
11:00 goban joined #perl6
11:00 yves_ joined #perl6
11:00 amnesiac joined #perl6
11:00 awwaiid joined #perl6
11:00 mr_ank joined #perl6
11:00 lumi joined #perl6
11:00 charsbar joined #perl6
11:00 autark joined #perl6
11:00 electrogeek joined #perl6
11:01 dolmans joined #perl6
11:14 obvio171_ joined #perl6
11:19 larsen_ joined #perl6
11:19 BooK joined #perl6
11:19 jisom joined #perl6
11:19 rashakil joined #perl6
11:19 goban joined #perl6
11:19 yves_ joined #perl6
11:19 amnesiac joined #perl6
11:19 awwaiid joined #perl6
11:19 mr_ank joined #perl6
11:19 lumi joined #perl6
11:19 charsbar joined #perl6
11:19 autark joined #perl6
11:19 electrogeek joined #perl6
11:20 obvio171_ joined #perl6
11:22 edenc joined #perl6
11:28 sbkhh joined #perl6
11:28 obvio171_ joined #perl6
11:31 statico joined #perl6
11:34 jisom_ joined #perl6
11:34 TimToady joined #perl6
11:35 obvio171_ joined #perl6
11:39 TimToady joined #perl6
11:44 TimToady joined #perl6
11:44 obvio171_ joined #perl6
11:44 Belaf joined #perl6
11:50 obvio171_ joined #perl6
11:51 TimToady joined #perl6
11:56 TimToady joined #perl6
11:56 obvio171_ joined #perl6
12:01 TimToady joined #perl6
12:04 obvio171_ joined #perl6
12:04 ruoso joined #perl6
12:06 TimToady joined #perl6
12:17 TimToady joined #perl6
12:18 obvio171_ joined #perl6
12:22 TimToady joined #perl6
12:25 obvio171_ joined #perl6
12:26 iblechbot joined #perl6
12:27 TimToady joined #perl6
12:37 obvio171_ joined #perl6
12:44 obvio171_ joined #perl6
12:45 TimToady joined #perl6
12:47 bernhard joined #perl6
12:50 TimToady joined #perl6
12:51 obvio171_ joined #perl6
12:53 ruoso joined #perl6
12:54 DarkWolf84 joined #perl6
12:55 TimToady joined #perl6
12:57 obvio171_ joined #perl6
13:00 TimToady joined #perl6
13:04 cognominal joined #perl6
13:05 TimToady joined #perl6
13:09 rindolf TimToady is bouncing.
13:10 TimToady joined #perl6
13:12 Patterner because he's happy?
13:15 TimToady joined #perl6
13:18 rindolf Hi Patterner
13:20 TimToady joined #perl6
13:28 TimToady joined #perl6
13:37 Belaf joined #perl6
13:38 TimToady joined #perl6
13:39 Belaf_ joined #perl6
13:43 TimToady joined #perl6
13:43 lisppaste3 joined #perl6
13:48 TimToady joined #perl6
13:54 jamessan joined #perl6
13:54 TimToady joined #perl6
13:55 jamessan left #perl6
13:56 pack|pizza joined #perl6
13:59 TimToady joined #perl6
14:04 TimToady joined #perl6
14:11 TimToady joined #perl6
14:17 TimToady joined #perl6
14:18 explorer joined #perl6
14:22 TimToady joined #perl6
14:27 TimToady joined #perl6
14:43 bonesss joined #perl6
14:44 TimToady joined #perl6
14:49 TimToady joined #perl6
14:54 TimToady joined #perl6
14:59 TimToady joined #perl6
15:04 TimToady joined #perl6
15:08 REPLeffect joined #perl6
15:09 TimToady joined #perl6
15:11 crashmatrix joined #perl6
15:14 TimToady_ joined #perl6
15:18 justatheory joined #perl6
15:20 TimToady changed the nick to TimToady_
15:22 TimToady I'm tired of bouncing now.  I think today would be a good day to replace my old Linksys... :/
15:25 edenc joined #perl6
15:44 fglock joined #perl6
15:52 fglock TimToady: I noticed that several parts of the v6.pm grammar can be just replaced with the STD equivs
15:52 fglock this is a possible path for STD to parse itself
15:57 TimToady cool!
15:59 TimToady if you need to refactor STD into chunks for some reason, feel free.  'course, cheat assumes it has the whole grammar when it generates its rules at the end...
16:00 fglock ok - I'll give it a try
16:01 TimToady but we can always cat *-STD.pm | cheat
16:02 fglock I guess I'll embed a "cheat" in the compiler, so that I can use the original version
16:03 TimToady but if you need to chunk things within the file, like group regex in a subgrammar, you can do that too.
16:05 chris2 joined #perl6
16:05 fglock you mean the original file, or the preprocessed one?
16:11 fglock I'm thinking about doing STD indexing, replace return-blocks with AST generator, save the v6.pm code and then generate perl5 pmc
16:11 mithraic joined #perl6
16:15 fglock re refactor STD into chunks - you mean the original file, not after 'cheat'?
16:16 penk joined #perl6
16:16 REPLeffect joined #perl6
16:17 TimToady I'm just explicitly giving you permission to restructure original STD if necessary, as long as the top level grammar ends up doing subgrammars.  but if you don't need to do anything like that, that's also okay.
16:17 fglock ok - thanks
16:17 fglock I'll try to use it as-is
16:18 TimToady just thinking you might run into unnecessary roadblocks with that approach, and I'll be out for a few hours, so trying to be "proactive"  :)
16:19 TimToady I know you're already lazy and impatient enough--just trying to convey a little more hubris in your direction.  :)
16:20 fglock yup - roadblocks were never a problem :)
16:21 edenc joined #perl6
16:21 fglock later &
16:21 ludan joined #perl6
16:22 fglock left #perl6
16:22 ludan hola
16:23 penk joined #perl6
16:23 TimToady aloha
16:24 TimToady konnichiha
16:25 autin joined #perl6
16:26 araujo konichiwa TimToady
16:35 yves_ joined #perl6
16:41 TimToady 散歩します &
16:43 offby1 why, thanks!  same to you
16:45 rindolf joined #perl6
16:47 rindolf Hi all.
17:04 cognominal joined #perl6
17:04 ruoso joined #perl6
17:17 knewt joined #perl6
17:36 Psyche^ joined #perl6
17:43 Patterner changed the nick to Psyche^
17:43 dduncan joined #perl6
18:24 Entonian joined #perl6
18:39 ludan joined #perl6
19:18 dduncan left #perl6
19:19 iblechbot joined #perl6
19:32 edenc joined #perl6
19:40 CindyLinz changed the nick to CindyLin1
19:51 mj41 joined #perl6
19:54 benny_ joined #perl6
19:56 SamB joined #perl6
19:57 ruoso joined #perl6
20:09 the_dormant joined #perl6
20:11 Aankhen`` joined #perl6
20:57 REPLeffect joined #perl6
21:04 [particle] joined #perl6
21:16 dduncan joined #perl6
21:39 Limbic_Region joined #perl6
21:46 the_dormant joined #perl6
21:54 stevan__ joined #perl6
21:55 edenc joined #perl6
21:57 REPLeffect joined #perl6
22:00 Limbic_Region salutations all
22:06 Aankhen`` Greetings, o ye of the region Limbic.
22:20 mithraic joined #perl6
22:40 buetow joined #perl6
22:50 avarab joined #perl6
22:52 SubStack joined #perl6
23:18 avar changed the nick to avarab
23:56 Entonian joined #perl6

| Channels | #perl6 index | Today | | Search | Google Search | Plain-Text | summary

Perl 6 | Reference Documentation | Rakudo