Upgrade to YAML::Syck 0.85 before smoking | moritz.faui2k3.org/irclog/ | pugscode.org | sial.org/pbot/perl6 | ?eval [~] <m oo se> | We do Haskell, too | > reverse (show (scanl (*) 1 [1..] !! 4)) | "Perl 6 Today" video from YAPC::Asia: xrl.us/v6op
Set by agentzh on 1 May 2007.
00:00 Khisanth joined
dduncan ?eval sub foo (Int $x --> Str) {...}; 00:11
00:11 evalbot_r16187 is now known as evalbot_r16189
evalbot_r16189 undef 00:11
dduncan ?eval sub bar (--> Str) {...};
evalbot_r16189 Error: ␤Unexpected "-->"␤expecting formal parameter or ")" 00:12
dduncan now, having routines without arguments is common, and I would have expected the second to work
pasteling "TimToady" at 71.139.27.123 pasted "Anyone recognize this build failure (ghc-6.6 from FC6 extras)" (424 lines, 27.5K) at sial.org/pbot/24691 00:13
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
that is, however, if <-- could be made to work in signatures, I would then prefer that, probably 00:14
TimToady no, Foo has to come before sub
dduncan right, Foo sub bar
TimToady which means you need a declarator before that: "my Foo sub bar"
though maybe we can relax that eventually 00:15
dduncan hm, perhaps I'll just leave the 'of' as is for now, since it already seems to work
or at least it doesn't cause a failure
TimToady the (--> is a known bug. the "cheat" translates it it ( *%_ --> 00:16
dduncan still, if <-- isn't in the spec yet, could it reasonably be made to work?
that is, put in the spec?
PerlJam dduncan: made to work how exactly? 00:17
TimToady generally you want the return type on the right if you're going to define it in terms of types on the left
you can't use T retroactively in a sig
dduncan I think the parity would be nice, as we have parity with feed operators <== and ==>
PerlJam TimToady: But I read right to left! ;-)
TimToady you're PerlJam, not Perl 00:18
dduncan it seems to me that having the choice of params --> return or return <-- params would be nice
TimToady next you'll be wanting <-
dduncan I wouldn't consider that to be the same situation 00:19
TimToady I don't consider <-- to be the same situation as <==
PerlJam dduncan: beware the hobgoblin of foolish symmetry :)
Though I have to admit that --> does seem like a syntactic oddity compared to the rest of the language (to me anyway) 00:20
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
I just thought making it look like <-- would be more intuitive if people already know -->
avar TimToady: How does the implicit $/ lexical "happen" after regex matches as it were? Macro in the compiler? 00:21
that's probably more implementorish:)
TimToady doesn't "happen" after the regex, except for binding to the existing $/ 00:22
the regex knows the $/ it's supposed to bind the result to
but the $/ variable is declared from the top, like $_ 00:23
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:23 amnesiac joined
dduncan I find having the return type first makes it closer to what actually uses it or what it describes in typical situations 00:24
TimToady 'course, you can argue that if you do want to specify a return type, it's exceptional, and should be in front
japhb TimToady: I forget, did you decide to differentiate multi by return type as well, or only args?
TimToady but in that case, bring it all the way out front
japhb TimToady: exactly
PerlJam Hmm. 00:25
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
dduncan I think the return type is just as much part of a signature as its parameters
japhb ... and when inside the parens, it should be last to me.
TimToady the of type is, but not the "returns" type
dduncan I refer to the 'of' type 00:26
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.
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:27
eg, wants_Int( returns_Int() )
TimToady sure, but we currently call that the "of" type 00:28
japhb I like the reduced backtracking of the Perl 6 grammar for mental reasons more even than for compile time efficiency
dduncan yes
TimToady if you declare a "returns Int" it is explicity not part of the sig 00:29
dduncan true, I should say that as wants_Int_param( of_Int() )
TimToady it's just an implicit coercion on all your return statements
dduncan I mean, has_Int_param
or wants_Int_arg
speaking generally, I like to use the strong typing features 00:30
things that let us move work to compile time from run time
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:32
TimToady could well be
maybe it's an "as" type or some such
dduncan I suggest renaming 'return' to 'coerce' or some such 00:33
the 'of' is fine
TimToady on return types for tiebreaking, this is discussed in S12:899
japhb Actually, I think changing returns to as sounds nice. Because 'as' says coerce, while being short and clearer to the common man 00:34
dduncan yes, that should work 00:35
'returns' to 'as'
and leave 'of' as is
japhb exactly
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:36
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:37
japhb Oh now that's interesting ...
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:38
so then that argument will only ever get Bool::False or Bool::True
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:39 Khisanth joined
dduncan yes, along those lines 00:39
japhb I like it
dduncan though for parity with routine return/of types, the second could be spelled either 'Foo $arg' or '$arg of Foo'
PerlJam FWIW, I like it too. 00:40
japhb feels a big 'as' normalization coming on ... :-)
PerlJam Though the shortness of "as" and "of" bother me a little bit.
(as far as differentiating the two)
dduncan I would think they are used a lot, so good huffmanizing
japhb I'm not delighted with 'of', but I'm not confused by it. 'returns' causes cognitive dissonance and confusion.
dduncan sure, they are both short, but they visually look quite different
as does either from "is" 00:41
japhb And 'as' gets nice and useful for any place we want a coerce done for us declaratively
As dduncan showed
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:43
this said, I'm thinking that certain matters related to the meaning of .does() may be impacted by this 00:44
japhb dduncan: how so? 00:45
dduncan for example ...
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:46
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:47
japhb If we only want to get Bool::True and Bool::False, we *do* want to coerce.
If you really, really only want Bool, and not something that .does Bool, you need to coerce.
00:47 scsibug`` is now known as scsibug
dduncan eg, "if $bool === Bool::True" should work 00:48
00:48 scsibug left
dduncan one moment ... 00:48
I'm thinking it is useful to differentiate between subtypes of a type and an object that can do that type 00:49
TimToady sub foo (::T $b where T === Bool)
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
japhb TimToady: that syntax makes some sense, but it's ugly 00:50
TimToady maybe it's ugly on purpose
japhb And it's still not clear if that is a hard constraint or a coersion without looking at the spec
dduncan I like strong determinism ... 00:51
TimToady unnecessarily restricting your arg types is construed as bad polymorphism, generally
no, you just think you like strong determinism. :)
japhb TimToady: I agree, but I can see good reasons for needing it available. 00:52
TimToady and ugly. :)
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
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
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:53
TimToady ?eval 1 as Num
evalbot_r16189 Error: ␤Unexpected "as"␤expecting operator
TimToady ?eval Num(1)
evalbot_r16189 Error: No such subroutine: &Num
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:55
TimToady dduncan: most Perl programmers would find such semantics abhorent
dduncan well, fair enough if some users want things less deterministic, but I like the option to be more deterministic 00:56
"more than one way" and all that
PerlJam perl isn't just for perl programmers is it?
dduncan unless you think providing the option just causes a lot of trouble? 00:57
japhb TimToady: were you showing what the syntax would be, but it's not implemented, or ... ? 00:58
TimToady all is fair if you predeclare
japhb (for as)
TimToady there used to be an "as" operator, but I think we deleted it in favor of Foo($x)
?eval 1.Num
evalbot_r16189 Error: No such method in class Int: &Num
TimToady but that isn't implmented
?eval 1.as(Num) 00:59
evalbot_r16189 Error: No such method in class Int: &as
dduncan personally, I think Num(1) does look better than 1.as(Num0
s/0/)/
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.
TimToady ::T $arg where T === Foo doesn't look the same 01:00
japhb OK, perhaps I'm not understanding the latter syntax ... I thought the where version was a constraint, not a coersion? 01:01
In the same way that subtypes constrain the set of possible values, rather than trying to coerce an Int to an Odd
TimToady Foo $arg can be coercing if Foo is defined that way, but that's the default only for Int/Num/Str types 01:02
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
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:03
PerlJam japhb: including inheritance coercions? 01:04
japhb Having Int/Num/Str coerce by default, and no other type coerce by default, has a design odor to me.
dduncan I'm not asking for different types to be treated differently 01:05
TimToady not really; they're that way because they define themselves appropriately
japhb PerlJam: why not?
PerlJam japhb: hmm. now it sounds real easy to paint yourself into a corner
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:06
japhb doesn't feel like he's communicating well today
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:07
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.
dduncan so eg, if " 42 " is passed to Int $foo, and I say "$foo", I want the spaces to be gone
that's actually the main importance 01:08
japhb dduncan: to you, perhaps. :-) 01:09
dduncan in that case, I do actually want the argument coerced to an Int, and not left unchanged just because it already does Int ...
or maybe that is a non-issue
... 01:10
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
dduncan makes sense 01:11
actually, this also is one of my concerns ...
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:12
Currently, I can create a new Num, assign my magic object to it, and hand it off, no problem ... 01:13
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:14
DRY and be transparent
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
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:15
s/assigns an array/passes an array arg/
japhb thinks 'my $foo as Seq' meaning 'Coerce to a Seq anything assigned in'
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:16
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:17
I want to be able to count on things not changing on me ... that's important 01:18
only if I explicitly declare a mutable type for a param type, eg asking for an Array, should I expect that it might mutate
japhb But isn't that what 'is copy' is for?
Aankhen`` sub foo (Bar $baz is exact)?
TimToady that makes it mutable
or makes it look mutable, anyway
Bar! $baz 01:19
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
TimToady but might be confused with Bar $baz!
dduncan in that respect, is copy should have no effect on an immutable typed param/arg
japhb I kinda like Bar! $baz.
Aankhen`` Maybe make people uppercase the type name if they want only that type. <G> 01:20
dduncan makes no sense when names are case-sensitive
japhb BAR_NO_REALLY_I_MEAN_IT $baz
Aankhen`` japhb: Exactly!
Aankhen`` points dduncan at the <G>.
dduncan I've been called to dinner, but will backlog ... 01:21
TimToady dduncan as Diner
japhb imagines dduncan in bright silver with a neon sign on his head
English ... because it's fun. 01:22
TimToady: are gears turning in your head, or are we just insane? 01:23
TimToady the two are not mutually exclusive 01:24
japhb (mmmm, tasty false dichotomy)
TimToady I can see arguments for Foo $x as Bar, but the common case is perhaps Foo $x as Foo 01:26
japhb seek_food & # Something that tastes very umami 01:27
TimToady which Foo! $x might be short for
mushrooms work
on the assumption that $x as Foo means Any $x as Foo 01:28
rhr mushrooms work on me without any assumptions :) 01:30
pasteling "rhr" at 65.94.38.10 pasted "proposal for IO/feed interactions" (16 lines, 499B) at sial.org/pbot/24693 01:40
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:44
nm:) sleep& 01:47
01:54 kanru joined 02:08 Khisanth joined
spinclad ?eval ~+' 42 ' 02:13
evalbot_r16189 "42"
02:14 kanru joined 02:20 kanru joined
dduncan and I'm back 02:22
02:29 kanru joined 02:44 yves_ joined 02:50 kanru joined 02:51 obvio171 joined 03:02 elmex_ joined 03:09 REPLeffect joined 03:16 justatheory joined 03:36 goban joined 03:45 kunwon1 joined, SubStack joined 04:04 fayland joined 04:26 obvio171 joined 05:20 rashakil joined 05:39 dolmans joined 06:08 obvio171 joined 06:14 [particle] joined
svnbot6 r16190 | Darren_Duncan++ | ext/QDRDBMS/ : added some methods to AST.pm 06:14
06:19 zzz_reaper left 06:22 dduncan left 06:24 gnuvince_ joined 06:29 justatheory joined 06:33 sunnavy joined 06:59 obvio171 joined 07:22 jisom joined 07:28 torz joined 07:30 BooK joined 07:42 source_guy joined 07:44 demq joined 07:56 source_guy left 08:40 ozo joined 08:44 ozo_ joined 08:49 obvio171 joined 08:55 obvio171 joined 08:57 iblechbot joined 08:59 REPLeffect joined 09:00 obvio171 joined 09:05 obvio171 joined 09:10 obvio171 joined 09:11 rindolf joined 09:12 ozo__ joined 09:13 obvio171_ joined
ingy hola 09:17
rindolf Hi ingy 09:19
ingy: what's up? How do you feel?
ingy i feel pain in my arm
and happiness in my heart 09:20
rindolf ingy: that's good, well at least except from the pain in your arm. 09:21
ingy i have an idea of how to use 'warnings' and 'our' in 5.5
rindolf ingy: why do you need perl 5.005? 09:22
ingy rewriting YAML.pm 09:23
people will be pissed if I require 5.8.3
:)
which I usually do now
09:23 franck__ joined
Tene What's the typical situation where people require an old perl but the latest YAML.pm? 09:24
ingy beats me 09:25
YAML::Syck supports 5.3.7! 09:26
09:27 larsen_ joined
rindolf Hmmm... File::HomeDir is broken. 09:49
ingy: I think you should aim for perl-5.6.2 09:56
ingy: perl 5.005 is an absolute brain-damage.
ingy rindolf: 5.8.0 is horrendous 09:58
:)
rindolf ingy: yes, that too.
ingy: VMware ESX still ships with it.
And so do many other RHELs.
ingy !
10:02 sreejesh joined 10:08 buetow joined 10:09 obvio171_ joined 10:12 larsen_ joined, BooK joined, jisom joined, rashakil joined, goban joined, yves_ joined, amnesiac joined, awwaiid joined, mr_ank joined, lumi joined, charsbar joined, autark joined, electrogeek joined 10:41 larsen_ joined, BooK joined, jisom joined, rashakil joined, goban joined, yves_ joined, amnesiac joined, awwaiid joined, mr_ank joined, lumi joined, charsbar joined, autark joined, electrogeek joined 10:42 riffraff joined 10:43 chris2 joined 10:57 elmex joined 10:58 larsen_ joined, BooK joined, jisom joined, rashakil joined, goban joined, yves_ joined, amnesiac joined, awwaiid joined, mr_ank joined, lumi joined, charsbar joined, autark joined, electrogeek joined 11:00 dolmans joined 11:13 obvio171_ joined 11:18 larsen_ joined, BooK joined, jisom joined, rashakil joined, goban joined, yves_ joined, amnesiac joined, awwaiid joined, mr_ank joined, lumi joined, charsbar joined, autark joined, electrogeek joined 11:19 obvio171_ joined 11:21 edenc joined 11:26 sbkhh joined 11:27 obvio171_ joined 11:30 statico joined 11:33 jisom_ joined, TimToady joined 11:34 obvio171_ joined 11:38 TimToady joined 11:43 TimToady joined, obvio171_ joined, Belaf joined 11:49 obvio171_ joined, TimToady joined 11:54 TimToady joined 11:55 obvio171_ joined 11:59 TimToady joined 12:03 obvio171_ joined, ruoso joined 12:04 TimToady joined 12:16 TimToady joined 12:17 obvio171_ joined 12:21 TimToady joined 12:24 obvio171_ joined 12:25 iblechbot joined 12:26 TimToady joined 12:36 obvio171_ joined 12:43 obvio171_ joined 12:44 TimToady joined 12:46 bernhard joined 12:49 TimToady joined 12:50 obvio171_ joined 12:51 ruoso joined 12:53 DarkWolf84 joined 12:54 TimToady joined 12:56 obvio171_ joined 12:59 TimToady joined 13:03 cognominal joined 13:04 TimToady joined
rindolf TimToady is bouncing. 13:07
13:09 TimToady joined
Patterner because he's happy? 13:11
13:14 TimToady joined
rindolf Hi Patterner 13:16
13:19 TimToady joined 13:27 TimToady joined 13:36 Belaf joined, TimToady joined 13:38 Belaf_ joined 13:41 TimToady joined 13:42 lisppaste3 joined 13:46 TimToady joined 13:53 jamessan joined, TimToady joined 13:54 jamessan left, pack|pizza joined 13:58 TimToady joined 14:03 TimToady joined 14:09 TimToady joined 14:16 TimToady joined 14:17 explorer joined 14:21 TimToady joined 14:26 TimToady joined 14:42 bonesss joined, TimToady joined 14:47 TimToady joined 14:52 TimToady joined 14:57 TimToady joined 15:02 TimToady joined 15:06 REPLeffect joined 15:07 TimToady joined 15:10 crashmatrix joined 15:12 TimToady_ joined 15:16 justatheory joined 15:19 TimToady_ is now known as TimToady
TimToady I'm tired of bouncing now. I think today would be a good day to replace my old Linksys... :/ 15:21
15:24 edenc joined 15:42 fglock joined
fglock TimToady: I noticed that several parts of the v6.pm grammar can be just replaced with the STD equivs 15:51
this is a possible path for STD to parse itself
TimToady cool! 15:55
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... 15:58
fglock ok - I'll give it a try
TimToady but we can always cat *-STD.pm | cheat 15:59
fglock I guess I'll embed a "cheat" in the compiler, so that I can use the original version 16:01
TimToady but if you need to chunk things within the file, like group regex in a subgrammar, you can do that too. 16:02
16:03 chris2 joined
fglock you mean the original file, or the preprocessed one? 16:04
I'm thinking about doing STD indexing, replace return-blocks with AST generator, save the v6.pm code and then generate perl5 pmc 16:09
16:10 mithraic joined
fglock re refactor STD into chunks - you mean the original file, not after 'cheat'? 16:14
16:14 penk joined 16:15 REPLeffect joined
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:15
fglock ok - thanks 16:16
I'll try to use it as-is
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:17
I know you're already lazy and impatient enough--just trying to convey a little more hubris in your direction. :) 16:18
fglock yup - roadblocks were never a problem :)
16:19 edenc joined
fglock later & 16:20
16:20 ludan joined 16:21 fglock left
ludan hola 16:21
16:21 penk joined
TimToady aloha 16:21
konnichiha 16:23
16:23 autin joined
araujo konichiwa TimToady 16:25
16:34 yves_ joined
TimToady 散歩します & 16:40
offby1 why, thanks! same to you 16:42
16:44 rindolf joined
rindolf Hi all. 16:46
17:02 cognominal joined, ruoso joined 17:16 knewt joined 17:34 Psyche^ joined 17:41 Psyche^ is now known as Patterner 17:42 dduncan joined 18:23 Entonian joined 18:38 ludan joined 19:16 dduncan left 19:18 iblechbot joined 19:31 edenc joined 19:39 CindyLin1 is now known as CindyLinz 19:49 mj41 joined 19:52 benny_ joined 19:54 SamB joined 19:56 ruoso joined 20:07 the_dormant joined 20:10 Aankhen`` joined 20:55 REPLeffect joined 21:03 [particle] joined 21:15 dduncan joined 21:37 Limbic_Region joined 21:45 the_dormant joined 21:52 stevan__ joined 21:53 edenc joined 21:55 REPLeffect joined
Limbic_Region salutations all 21:59
Aankhen`` Greetings, o ye of the region Limbic. 22:05
22:19 mithraic joined 22:39 buetow joined 22:49 avarab joined 22:50 SubStack joined 23:17 avarab is now known as avar 23:54 Entonian joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!