-Ofun: xrl.us/hxhk | pugscode.org | pugs.kwiki.org | paste: paste.lisp.org/new/perl6 or sial.org/pbot/perl6
Set by apple-gunkies on 11 November 2005.
svnbot6 r7970 | Darren_Duncan++ | r861@Darren-Duncans-Computer: darrenduncan | 2005-11-18 12:46:27 -0800 01:14
r7970 | Darren_Duncan++ | /ext/Rosetta-Incubator : added SEE ALSO to indicate dependents of 5 core modules
r7971 | Darren_Duncan++ | r863@Darren-Duncans-Computer: darrenduncan | 2005-11-18 13:23:48 -0800
r7971 | Darren_Duncan++ | /ext/Rosetta-Incubator : updated LICENCE AND COPYRIGHT in Validator.pm and all 8 en.pm files to briefly refer to their core modules for details rather than verbosely reprinting them
r7972 | Darren_Duncan++ | r865@Darren-Duncans-Computer: darrenduncan | 2005-11-18 13:52:17 -0800
r7972 | Darren_Duncan++ | /ext/Rosetta-Incubator : updated ACKNOWLEDGEMENTS in the same 9 files likewise
r7973 | Darren_Duncan++ | r867@Darren-Duncans-Computer: darrenduncan | 2005-11-18 17:05:59 -0800
r7973 | Darren_Duncan++ | /ext/Rosetta-Incubator : in each of the 17 lib/*.pm files, split up the NAME pod into 2 lines 01:15
rafl leo: Ah, OK. 02:11
08:36 khisanth__ is now known as Khisanth
gaal autrijus: ping 11:20
autrijus: we have dates for YAPC, finally 11:30
26-28 Feb
theorbtwo Febuary?
YAPC::Na?
gaal we'd like to do the hackathon 21-25 maybe? 11:31
theorbtwo: YAPPC::Israel
theorbtwo Aaah
christopher_ luqui: ping 11:58
luqui christopher_, pong 12:04
christopher_ I thought about things you worried about in your journal entry about a week ago. 12:07
First thought: The only problem with making Natural do Ring is with the return type. So, for multiple-dispatch, subtypes are okay for parameters, but not
for return values.
luqui sure 12:08
christopher_ Are subtypes actually full-fledged classes? 12:09
luqui well, I'd like to answer you, but I'm afraid "class" is something we still haven't defined :-) 12:10
christopher_ I came to the conclusion that maybe they shouldn't be. If something was
inherited from Integer, then it should inherit the Ring role. But I
don't think a subtype should.
the first "inherited" should be "derived"
luqui yeah... um. so if you inherit from integer 12:11
you are specifying a subset of the integers, right?
I mean, anything that is your derivation of integer is also an integer is a subset
but the only subsets of the integers which are rings are {0} and all the integers
christopher_ No, that's what subtypes are for. If you derive from integer, you're 12:12
basically an integer but you represent something more special and so you
have extra, pretty little functions attached.
luqui but what if you also have extra data attached?
certainly "1" is not your special derived integer, because it doesn't have the pretty data
and then your ring doesn't have a multiplicative identity :-)
christopher_ If you have extra data attached, then you still do Ring by forgetting 12:13
the extra data. If the extra data makes Ring ambiguous, well, that's
what my other proposal is for.
luqui that's the subtyping *within* the ring you're talking about
the set of your specialized integers still does not do the ring
but they can certainly be used as elements of the ring.
you're just not guaranteed to get a specialized integer back again
let's call it MyInt 12:14
That is, Ring{MyInt} is still not true
even though you may certainly use MyInt in Integers place if MyInt is a subtype (or subclass or whatever) of Integer
christopher_ By "derived" above, I mean class B isa A. I'm distinguishing the "isa"
relation from the "subtype" relation.
luqui sure. but when you reduce it to fundamentals, you realize that they're both just certain kinds of subsets 12:15
here's what I'm saying:
if Ring{MyInt}, that means there is a method infix:<+> (MyInt, MyInt --> MyInt)
if Ring{Int}, that means there is a method infix:<+> (Int, Int --> Int)
If MyInt isa Int, then you can still pass MyInts to the latter function 12:16
but you might not get a MyInt back
christopher_ When you have "isa" class inheritance, you can think about properties of
the group as a whole. When you use subtypes, then lots of your methods
may fail. Subtypes work fine for many self-invoked methods but as you
observe the multiple-invocant start making less sense, because there's
no concept of the "subtype as a whole" having nice properties.
luqui If Ring{MyInt} were true, that means you'd have to define a infix:<+> where if you added two MyInts, you'd get another MyInt back
christopher_, what is "isa" inheritance in the presence of multimethods? 12:17
you can fail there, too 12:18
only in the single-invocant case are you guaranteed still to succeed
but Ring defines lots of multimethods.
I'm not sure what you mean by "when you have 'isa' class inheritance, you can think about properties of the group as a whole' 12:20
christopher_ With isa inheritance, aren't all the Int variables and methods automatically 12:24
visible in the derived class?
You're right, you could recede to the base type when you call some of them..
luqui with subtyping, isn't the *exact same* value automatically visible in the derived class? 12:25
I think of subtyping as derivation without adding any methods or data
(though construction is certainly different) 12:26
christopher_ So, how about trying to separate covariant and contravariant promises? 12:28
Role gets into so much trouble by trying to satisfy both of them at once...
at least, it makes it impossible for it to deduce much of anything.
luqui did you read theory.pod? 12:29
christopher_ parts of it. why, are they already separated?
luqui the idea was: role: contravariant only; factory: covariant only; theory: both
(but I called them the opposite things, as TSa hadn't corrected me yet) 12:30
christopher_ But roles aren't contravariant-only in A12, are they?
luqui sure 12:31
they're even more restrictive
you can only have the topic type (the type being defined) in the first invocant position
christopher_ so, the problem is with Ring as Theory?
luqui the problem is in the expansion law; the rules that I use to transform the "sugared" form into constraints on variables 12:32
it doesn't work
in order to solve it, I have to introduce "theory-valued theories" (theories that take other theories as parameters)
which I imagine could be a major pain for the typechecker 12:33
christopher_ "Theory-valued theories" were already in theory.pod before yesterday 12:34
(though admittedly, I didn't read that part).
luqui oh, yeah, the note at the end
I was hoping that I could eliminate that 12:35
and then I did. but now I realize that I *really* can't
(it's a much bigger problem than the GADT case mentioned at the end)
christopher_ So, I'd imagined that if you needed contravariant promises and covariant 12:38
ones at once, you wouldn't be able to inference anything non-explicit.
But you say that with this extra machinery, there are some special
inferences you'll be able to make about Ring?
luqui with what extra machinery?
christopher_ theory-valued theories
..
luqui uh, no. they're necessary just to express the kinds of algebra that people want to express 12:39
you couldn't make a Functor class without them.
oh, you were talking about inference 12:40
but maybe you weren't... the rest of your sentence doesn't seem to suggest that you're talking about type inference.
christopher_ I think I was talking solely about type inference. 12:41
luqui hmm... okay, let me figure out what you were saying then :-)
christopher_ maybe I should just ask a different question: why are theories necessary for p6? 12:42
luqui well, they're not *really*. We could settle for a Java-like type system 12:43
christopher_ okay, why do we want theories in p6?
luqui Theories are really just an extension of Haskell's type classes. And type classes rock. So we stole them.
In most type systems, which don't have them, you can't even express algebraic structures like Ring 12:44
You just settle for assuming it implicitly in your program
It's really kind of obvious. We're all about generalization. You can think of theories either as a generalization of classes to multiple parameters, or a generalization of multimethods to collections of related multis. 12:46
s/classes/roles/
christopher_ By the expansion law, do you mean the place where you rewrite your 12:47
simple syntax and put in '<=' a few times?
luqui Yeah.
Haskell makes you write: sort :: (Ord a, Ord b) => [a] -> [b] 12:48
and I thought that was linguistically and conceptually complicated
so I wanted to be able to write it: sort :: [Ord] -> [Ord]
It gave a meaning to putting a role in a signature, since a role was just a theory
christopher_ that may have led to my question about signature syntax, and how 12:49
you express that whether the ord's are supposed to be fulfilled by
the same or different classes...
luqui ahh, if you require them to be fulfilled by the same class, you have to use a variable
hmm, maybe the flaw in the rewrite syntax was the existential flaw I made in haskell the other day 12:50
do you know haskell?
(to know whether I should put it in haskell or perl 6 syntax)
(because p6 syntax isn't as well-defined)
christopher_ i'm trying to learn it. I'm up to chapter 9 in the gentle intro, and
have just discovered that 'local' is provided by the Reader monad...
luqui that's definitely good enough
basically, I was trying abstract away my implementation types. 12:51
so I had a function: mkFoo :: (Foo a) -> a
and I defined it: mkFoo = ImplFoo, where ImplFoo was a constructor for a type that was an instance of Foo (whew)
and then ghc whined at me about it 12:52
oh, s/->/=>/ above
I was making a logical error
my signature says that *whatever* type a you give me, if it is an instance of Foo, I can return it
whereas I was thinking, there exists a type a that is an instance of Foo that I return 12:53
And the latter is what I'm thinking when I say: sub mkFoo(--> Foo)
so clearly the expansion law doesn't work there either
in the "returns" position, the type has to be existential, not universal
so I think I was bound to hit a wall in the big picture eventually 12:54
(because mkFoo is equivalent to sub mkFoo(--> ^T <= Foo{^T}), which is the same as the haskell example)
christopher_ remind me what the --> means? 12:56
luqui "returns"
however, it is very early in the morning, and I think it's time for me to go to bed 12:58
nice chatting with you; it clarified *my* thoughts a bit
I hope it did yours too
sayonara
christopher_ thanks for bringing me up to speed! i definitely need more ghc prractice. 12:59
svnbot6 r7974 | iblech++ | * Usual svn props. 13:07
r7974 | iblech++ | * New t/oo/attributes/defaults.t:
r7974 | iblech++ | has $.foo = get_foo(); # &get_foo executed at compile-time
r7974 | iblech++ | has $.foo = { get_foo() }; # &get_foo executed at object initialization time
r7974 | iblech++ | * New t/oo/attributes/is_rw_on_class.t:
r7974 | iblech++ | class Foo is rw {
r7974 | iblech++ | has $.bar; # automatically "is rw"
r7974 | iblech++ | }
Juerd Hmm 13:40
What does class Foo { has $.foo; is rw; has $.bar; } do?
(a) invalid syntax: is and friends have to come before anything else
(b) both $.foo and $.bar are rw, because is influences the entire class 13:41
(c) $.foo is ro, $.bar is rw, because is rw works lexically
14:08 < svnbot6> r7974 | iblech++ | has $.foo = { get_foo() }; # &get_foo executed at object initialization time 13:42
Eek!
But it should assign a closure.
Or does "my $foo = { ... }" also not assign a closure?
Symmetry must be 13:43
theorbtwo ?eval my $foo = { 1 }; $foo;
13:43 evalbot_7969 is now known as evalbot_7974
evalbot_7974 \sub {...} 13:43
Juerd luqui++ # apparently changed evalbot :) 13:45
svnbot6 r7975 | iblech++ | * Changed $:foo to $!foo, per latest S12 (r6618) in examples/, t/, ext/, and docs/. 14:01
r7975 | iblech++ | * Changed $self.:bar to $self!bar, same reason, same directories.
r7975 | iblech++ | * Changed method :foo to my method foo, same reason, same directories.
r7975 | iblech++ | * Pugs.Parser: Parse $!foo.
r7975 | iblech++ | Note: Calling of private methods (self!foo) is not yet parsed.
14:05 lampus_ is now known as lampus
Juerd There goes infix none() :( 15:01
r0nny_ ls 15:04
qmole :) 15:05
r0nny_ how does adding new stuff to Ī©INC work in perl6 ? 15:06
Juerd ...OhmINC?! 15:09
r0nny_ i found - again a 'foo" typo :/ 15:10
Juerd Hoping you mean @INC, it's no different than in Perl 5, BEGIN { push @INC, ... }
r0nny_ im doing use lib 'foo'; 15:12
it threw totally unrelated error messages at me casue i wrote 'foo";
is there a way, to allow special classes to read pricate methods of other classes ? 15:14
eh provate 15:15
dudley_ Does anybody have an svn dump of the pugs repo so that I could bootstrap my svk mirror? 16:23
I lost my repository and I don't really want to pull down 10000 revisions from svn. 16:24
nothingmuch lost it too today 16:25
integral dudley_: there is an option to sync to limit how much it pulls 16:29
dudley_ Oh, I know. It's just an OCD packrat thing, I want to have the whole history. 16:30
22:40 _SamB_ is now known as SamB
Jthon Hello 23:38
rafl Hello Jthon
Jthon Is there anyone around who would be willing to answer some questions about threading in parrot? 23:39
liz6 wouldn't #parrot be a better place to ask this?
Jthon Well there is all of one person there, and it is the perl6 vm.
rafl Jthon: #parrot on irc.perl.org 23:40
obra Jthon: What do your questions look like?
Jthon I'm just trying to write some PASM/PIR code that starts additional threads and runs code in parallel. Unfortuneatly the calling code doesn't seem to work correctly. 23:41
The only example I have is thr-primes.imc and that doesn't work either.
Same error as I get.
obra So. It's my understand that parrot threading isn't yet specced ;)
Jthon Which is get_str() not implemented in class 'NCI'
That's dissapointing. 23:42
leo Jthon: calling code wrt threading is currently not working at all - it was though
Jthon: get_string() 23:43
but as said that belongs to #parrot, which is at L<irc://irc.rhizomatic.net>/ or L<irc://irc.pobox.com/> 23:44
Jthon Ok I'll try there then. 23:45
I'm trying to get Parrot running on a HW transactional memory system, and need some benchmarks.
leo obra: and that too of course
Jthon thanks for the help
leo these exists already: 'HW transactional memory system'? 23:47
Jthon Well not entirely
Its running in a simic simulator as its still in development.
leo simulator?
<- #parrot 23:48

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!