% particle has left particle!~particle@144.81.84.156
% particle has joined #parrotsketch
% leo has joined #parrotsketch
<chip> prehi
<leo> hi chip 
<chip> not to have a pre-meeting meeting or anything, but that whole newclass-derived-from-Integer thing has short-circuited my frontal lobes
<obra> in a good or bad way?
<chip> well, it's always good to be in touch with reality, but it's a bad reality.  so I'll call it a draw.  :-)
<obra> also "poke" on the mail I send you
<chip> yeah.
<chip> I have to decide whether to give up on basic types morphing or on user classes deriving from them, or come up with a solution to that.  Then I can move on to the namespace roundup etc.
<chip> Riddle me this, since you understand MMD better than I:
<chip> Assume PIR code which does something like the Perl 6 'my Integer $x = MAXINT; $x++'
<chip> *if* $x morphs into BigInteger, will the MMD mechanism actually break, or will it follow the new type on the next dispatch?
<leo> all method calls and MMD will dispatch as BigInt thereafter
<chip> figured as much.  wondered whether there was any caching by PMC*
<chip> or only by type#
<leo> that is both Integer and BigInt must have the very same methos/MMDs
<chip> it would be user error to design a class that morphs into something less capable
<leo> the current MMD cache is a 2-D table, but we can't keep it as that (too big)
<chip> OTOH, even if BigInt isa Integer, the extra Manhattan Distance could throw off a user's carefully designed MMD system
<leo> yep
<chip> Also, if a ParrotClass lists itself as isa Integer, even if the internal Integer instance morphs, it will still claim to be isa Integer
<chip> (right?)
<leo> after morph to BigInt MyInt isa BigInt
<leo> and BigInt doesn't claim to be an Integer at all
<leo> which is probably correct as all the internals are different
<leo> so from parrot's POV a Integer->BigInt morph is as big as e.g. Integer->Complex
<chip> grr
<chip> the whole type system is morph-averse
<chip> btw, ISTR that the ParrotClass has an explicit list of type IDs, it's notional @ISA
<chip> how does the morphing of the internal Integer object change that?
<chip> s/Class/Object/ I mean
<chip> if the details are too big for IRC then never mind, it's not important
<leo> np, but the ParrotObject doesn't do the math - the value does it
<leo> well, we'd need 2 type ids, one for the perl6ish Int and one for the value
<chip> ok
<leo> the ParrotObject is the thing you get in Perl6 with 'my Dog archie;' (but it's not exposed as such in Parrot yet)
<chip> what do you mean "as such"?
<chip> the lexical $archie isn't tagged as "I'm guaranteed to be isa Dog"?
<leo> there is no way to get a PMC for that 'proto-object'
% allison has joined #parrotsketch
<chip> I see no proto-object here
<leo> you can only get a real object
<leo> my archie .= Dog.new();
<chip> oh wait, I think I remember now, the proto-object is ... yeah, but you didn't do it right.
<chip> I tihnk it's  my Dog $archie; $archie .= new()
<leo> yeah - missing '$' - sorry
<chip> the key is that you don't say "Dog", not the missing "$"
<chip> once you declare Dog you don't have to repeat yourself (in p6)
<leo> yep
<leo> but we can't do the first step yet
<particle> can't that be done with a P6-specific pmc?
<chip> I think that's gonna be Audrey's job.  Perl6 lexicals will either be a special ParrotObject or there'll be some fancy handwaving when the target of a .= is PMC null
<particle> just what i was thinking
<leo> we need some more syntax for that, maybe just a method 
<chip> my Dog $spot   will be implied   my Dog $spot = Perl6PseudoObject(Dog.typeid)
* chip & # afk
<obra> wait!
<obra> when will you be back, chip?
<particle> obra: you shut the barn door too late ;)
<obra> next time: shackles
<obra> parrotsketch roll call! who's here?
* allison is here
<allison> I see: leo, audrey, particle, cognomial
<obra> But are they at their keyboards? ;)
<leo> asdf
<allison> dunno about audrey
<obra> leo's cat is
<leo> yup
<obra> audreyt vanished off to $work recently, I think
<obra> but we'll see
% pmichaud has joined #parrotsketch
<particle> hi patrick
<obra> Hi all.
<obra> Shall we get cracking?
<pmichaud> hiya, particle 
* obra looks around the room and points at....
<obra> particle. How are things?
<particle> well.
<particle> i've been extending pge's rule compiler, in prep for the bnf parser
<particle> it can also redirect output, to make makefiles happier
<particle> noticed that the rt queue is growing larger, some triage/cleanup should probably be done soon
<particle> EOR
<obra> Anything that can be done to make your parrot-life more fun?
<allison> we could delete a bunch of TODOs that aren't actually tickets :)
<particle> pay me :)
<allison> wish I could :)
<particle> actually, with money comes hassles. i'm maxed out on fun, for the time i have
<obra> ok. allison?
<allison> mainly PDDing
<allison> I sent I/O off to chip, but still need to expand it in some places
<allison> I'm going to run through today or tomorrow and do very quick first versions of events, exceptions, and threads
<allison> will's been taking off on APL/Punie
<allison> (it would probably be less confusing if he stopped calling it Punie, though :)
<allison> he's had the occasional question
<allison> EOR
<allison> AFAICR
<obra> ok.
<obra> is speccing fun? or at least interesting in that eats-your-brain way?
<obra> Are there PDDs you'd like someone else to take a first stab at?
<allison> I'm having fun
<allison> let's see...
<allison> any unicode experts?
<leo> well, not expert, but ...
* obra wonders if we could draft kogai-san
<allison> there's a further qualification, though, and that's the ability to not hold to tightly to any one plan
<allison> that is, it's chip's decision, and what we need more than anything is a summary of the options
<obra> nod
<allison> that, and the willingness to dig into Parrot and see how it works now
<obra> ok. 
<obra> I'll see him next week in japan
<allison> cool
<obra> and poke
<obra> ok. chip?
<allison> even if he doesn't want to write the PDD, we can pester him with questions
<obra> sure
<obra> recruitment == good
<obra> ok. chip's net is broken
<obra> leo?
<leo> * finished major parts of namespaces as far as pdd21 is grokable for me. Todo: 
<leo>   - how (un-)typed is Parrot's default namespace?
<leo>   - interaction of .namespace [] and newclass/subclass still waits for confirmation
<leo> * added namespace_dump.pir example showing current state  
<leo> * more PIR codegen brainstorming with Audrey, Hackathon ended Wed.
<leo> * did some code cleanup, e.g. remove dead opcodes
<obra> (chip is working to restore his net)
<leo> EOR
<obra> what's next on your list?
<leo> dunno yet
<obra> just those two todos?
<obra> nod. stick on your list: updates to the parrot milestones document :P
<obra> (I'm starting to get poked about our april 1 update to the sponsors)
<leo> well, the (un)typed thingy has many implications
<leo> but chip is aware of that
<obra> ok
<leo> some internals need to be layed out too, it looks like 
<leo> e.g. var/value behavior of PMCs
<leo> or perlish str vs Str
<leo> so I'm basically blocking a bit on chip now
<obra> ok.
<obra> Is it worth going back to the things we think are done for milestone 2 and poking at them to make sure they're still at the "Done" state?
<obra> while you wait
<leo> a base implementation is there for almost everything
<leo> threads are currently deactivated due to calling conv changes, though
<allison> leo, which bits of milestone 2 have we paid for so far?
<leo> don't ask me ;)
<obra> We can poke ovid/dave for the list
<obra> I'm told chip is back. Let's move forward with the reports
<obra> chip?
% Coke has joined #parrotsketch
<Coke> *poof*
<obra> close. not quite, though
<obra> (chip msged to say he was back. but failing chip, patrick?)
<pmichaud> hello, all.  Busy week here
<pmichaud> I added "return values" to PGE, consistent with the late-february updates to S05
<pmichaud> thus closures can return a value into a match, and the match object uses the return value (instead of the string actually matched) for various return operations
<pmichaud> I'm also about this  ---> <---  close to being able to publish a perl 6 parser (more)
<pmichaud> but I discovered that parsing list ops is a bit of a challenge in the operator precedence parser, so I'm redesigning it slightly to try to handle it
<pmichaud> if it doesn't work out, then Larry has said it'll  be okay to do that portion of the parse using top-down parsing, but I still want to make the attempt at bottom-up
<pmichaud> in fact, during discussions yesterday on #perl6, I decided that the bottom-up parser could use some refactoring and improvements, so that's basically what I did yesterday
<pmichaud> even if the refactored bottom-up parser doesn't end up working out for parsing listops, it's going to be a lot less complex and more efficient than the one we have now
<pmichaud> Allison, Will, the changes to the bottom up parser might affect Punie and APL, but I'll try to update those as well or work with you to resolve any issues
<allison> ok
<Coke> k.
<allison> I don't mind a little shake up for progress :)
<pmichaud> Last week I spent the better part of a day trying to figure out why PGE was having trouble on my x86_64 platform; it kept being unable to find symbols in the global namespace.  I suspect this is related to the namespace changes Leo was making
<pmichaud> everything worked fine (as in "all tests pass") on 32-bit x86, so I switched over to that for development until I could get x86_64 working again
<pmichaud> I checked this morning and all tests pass on x86_64 again, so I'm guessing (hoping) whatever was causing the issues is now gone
<pmichaud> jesse, I still owe you updates to the milestones document, and will do that.  Hope you don't mind if I prioritize code over document for another day or so
<obra> ok
<leo> pmichaud: last time I checked x86_64, it was ok again - please report if it's still failing 
<pmichaud> leo:  yes, that's what I got as well this morning.  If I run into problems I'll just file an RT ticket saying "it's happening again".  (more)
<pmichaud> It's very difficult to write good test cases for when it fails, and I can empathize with the difficulty of being able to solve problems you can't reproduce :-)
<leo> I've an x86_64 box that I can ssh into - np
<pmichaud> the changes I'm making now should give things a good workout, so we'll know by tomorrow :-)
<pmichaud> end of my report, I think
<obra> cool.
<pmichaud> I have one question, unless Coke asks it first :-)
<obra> sounds like you're cranking through.
<obra> we still have a couple reports left
<obra> audreyt: you here?
<obra> coke: you here?
<obra> chip: you here?
<Coke> pong.
<obra>   you win!
<obra> what's new?
<Coke> Committed what is basically a placeholder for APL at the moment. Got some progress on converting punie to APL (which is basically what I am at the moment.) Some issues with reading in utf8 files (which leo has pointed to a fix for, but I'm hoping someone more C-capable will take). Doing some research on syntax, etc.
<Coke> end of line
<obra> cool
<obra> chip: audreyt: if you appear, feel free to report
<obra> otherwise, it's Question Time!
<obra> pmichaud: go for it
<pmichaud> coke alluded to it already -- reading utf8 files (more)
<pmichaud> this is going to become fairly important for the perl6 compiler as well, since there are at least a few  utf8 characters that can appear in source code
<Coke> (RT#38733)
<pmichaud> sounds good.  I suspect that there can be a quick fix, but it may also point to the need to have the io PDD available and implemented on a quicker timeline (I don't know what the other priorities are at the moment)
<obra> ack. fiancee is locked out of the house. I need to run. Apologies. I'll see logs
<pmichaud> later, obra
<pmichaud> that's my one question for now.
<pmichaud> I'll just track the RT ticket
<particle> pm, allison: does pge's return object mean that pge now overlaps with tge's functionality?
<allison> sort of
<allison> it means that you can use pge in place of the first transformation
<pmichaud> ooooh
<pmichaud> nice :-)
<pmichaud> glad I implemented it
<particle> pmichaud := megalomaniac :)
<allison> (that is, if I understand correctly that you can return a custom object for every node, completely eliminating PGE::Match objects)
<allison> :)
<particle> allison, that's how i understand it, too. but i understand pge better than tge, so i asked
<pmichaud> it doesn't eliminate them, it just means that the return value is used for stringify, numerify, and coercion ops
<allison> tge and pge are very similar
<allison> the main difference is the input format
<allison> pge takes string input, tge takes tree input
<particle> tree as in objects?
<allison> hmmm... then I'd say pge doesn't replace the first transformation, but it can simplify the job of the first transformation
<pmichaud> I remember another comment I wanted to make, which is that if any of you have anything you'd like to see different in PGE's parsing (especially the operator-precedence part), now would be a very good time to let me know :-)
<allison> particle: tree as in objects, hashes of hashes, arrays of hashes, etc
* chip is back, has short report & Q for Allison
<Coke> does the operator parser deal with monadic, dyadic, and ternary operators?
* allison is virtual obra
<pmichaud> pge still has to return match objects because they still have to be able to report ".text", ".from", ".to", etc., as well as have places for storing positional and named captures
<pmichaud> coke:  yes, as well as operators with optional terms
<allison> patrick: that makes sense
<particle> pm, allison, thanks. that clears matters up a bit for me. looking forward to tighter pge/tge integration, too
<allison> let's go with chip's report and then resume questions
<chip> Last week's discussion of value types vs. mutability led to a discussion of morphing, which led to me finally noticing a schism in Parrot's value model
<chip> Given C<class MyInt is Integer; my MyInt $mi> (sorry for the pidgin Perl 6),
<chip> it's obvious that for consistent MMD it's very important that the manhanttan
<chip> distance (MD) between MyInt and Integer remain 1.  But that goal can't be
<chip> achieved while also doing the right thing <$mi = MAXINT; $mi++>.
<chip> Without morphing, ++ doesn't work,
<chip> += doesn't work, and even '=' doesn't work.
<chip> But with morphing, the MD becomes inconsistent.
* particle suggests harnessing wormholes
<chip> it's close to that
<particle> you need a special case distance function for promotion
<chip> We either have to cheat on MD ("I'm really a BigInt but dispatch me like an Integer") or cheat on ++ ("$x++" is syntactic sugar for "$x = $x + 1").
<chip> Both of these are serious disruptions.
<chip> In other words, you can't have a consistent MD and also preserve value on mutation.
<chip> because consistent MD forces a limited range for the type, and if you want to store a value that doesn't fit in the range, the irresistable force meets the immovable object.
<chip> allison: what does Perl 6 say about C<my Integer $x = MAXINT; $x++>?
<leo> s/Integer/Int/ ;)
<pmichaud> Perl 6 intrinsically supports big integers and rationals through its system of type declarations. Int automatically supports promotion to arbitrary precision. [...]
<pmichaud> (from S02)
<allison> aye
<chip> Good background info but not an answer, I'm afraid.
<allison> afaik, $x++ is $x = $x + 1
<pmichaud> I agree, not an answer
<allison> (I'm not sure I'm clear on the question)
<leo> according to audreyt the variable $x get's a new value, which happens to be a BigInt in that case
<chip> allison: after $x++, is typeid($x) guaranteed not to have changed?  also, after $x++, is \$x unchanged (i.e. is it guaranteed still to be the same object it used to be [modulo tying anyway])?
<chip> [leo's answer says "no" on the first one]
<allison> ah the question is about autopromotion
<chip> mutation generally, though autopromotion is one common case
<leo> $x has still the type 'Int'
<allison> for the built in objects, particularly built in low-level types, you have no guarantee that the type will stay the same
<chip> leo vs. allison: FIGHT
<allison> integers may be autopromoted to BigInts
<allison> :)
<leo> well, one is parrot level, one is P6 level - we can't mix that fight ;)
<chip> allison: in p6,  BigInt isa Int?
<allison> yup, they're entirely separate
<leo> there isn't a BigInt in P6
<leo> it's just 'Int'
<allison> I'd say BigInt does Int
<chip> leo: well, for now I'm asking about Perl 6, if Parrot issues aren't directly relevant please delay
<allison> that is, there isn't an inheritance relationship
<allison> but you will have some way of checking "does this thing fulfil the need to store an integer"?
<chip> To summarize:  Int is a role.   as long as a value does Int then it's OK for the runtime to store a valu eof that type in $x.  And the type can change, and the actual value identity can change, on a mutation op like ++ or += or .= or ...
<chip> this is the Perl 6 way.
<allison> yup
<pmichaud> (leo is correct that the synopses don't seem to make any mention of bigint.  This again doesn't answer the question posed, but thought I'd mention it.)
<allison> it's Perlish
<allison> don't depend on implementation details
<chip> But it totally dismissed the magic variable model.
<allison> but do the right thing
<allison> how so?
<chip> The Perl 6 equivalent of $| implements $|++ ina  way that might end up storing a value that isn't a BufferMagic.
<chip> ... but of course you're doing your operatoins with MMD.  So you would never get to that point, right?
<allison> hmm... I figured the particular class would decide whether it's mutable
<particle> if it's done by roles, then $| can 'does' a role that's not mutable
<particle> ...what allison said... who decides whether a class/role is mutable?
<allison> Is the mutation externally imposed?
<allison> Or does the object  mutate itself when the situation demands?
<allison> The latter is closer to Perl 5's string->int->float type of mutations.
<chip> my Intenet is so bad I've switched to my cell phone
<allison> particle: whoever implements it
<chip> the object mutating itself is what I've been planning on all this time, from Topaz forward
<leo> mutability has to be builtin into the thingy e.g. array, but in the pugs model, the scalars are immutable
<allison> that is, if you're implementing a tied class, then you know it can't mutate to another class without problems
<chip> What I'm seeing now is that the type tree for Perl 6 and the type tree for Perl 5 will be 100% disjoint.  We can't use Perl 6 behaviors in a Perl 5 environment, ande vice versa
<leo> yep
<chip> MMD on Perl 5 values will not be effective
<chip> becaues they will have to morph to maintain the Scalar symantics we've come to know and/or love
<chip> (tying in particular, but there are other cases)
<allison> well, that makes sense
<allison> the semantics of MMD are language-dependent
<allison> you can't use MMD from one language to another
<chip> it's worse than that
<chip> MMD only works when you havea  consistent type, and Perl 5 (with its 'tie' and autoconverstion string/int) doesn't match well that model
<allison> (and can't use MMD in a language that doesn't use MMD)
<chip> allison: as the CLR example teaches us, all languages that run on a VM will be extended to use the VM's features, even if the original language dialect didn't contemplate them
<allison> the autoconversion string/int is sticking around in Perl 6
<particle> perhaps nicholas could provide a sanity check with that
<chip> MMD may yet be a useful implementation technique for the Perl 5 language targeters
<allison> all this says to me is that we don't have our MMD model speced out yet
<chip> allison: autoconversion is no biggy when you have a value object model, which is probably why Larry chose it, despite its performance hit (in the most common data types (which I would not have tolerated))
<chip> Well.  It does seem to me that types should advertise whether they mutate, and if they do, they shouldn't be allowed as base classes.
<allison> that is, we've identified that one of the requirements is to provide at least limited MMD to other languages
<allison> they can be allowed as base classes
<allison> the inheriting child just needs a way to override the mutation if they don't want it to happen
<chip> allison: it's not so bad as you may think< I believe..  For example, if all Perl 5 scalars are arranged to be isa perl5::core::scalar, then MMD on that type will mostly work
<allison> (if they want it to happen, they just inherit the mutation code)
<chip> allison: methods that could cause mutation must be overridden in the derived class?
<allison> can be overridden, not must be
<allison> if the parent class had the mutation, there's likely a good reason for it, and the child may have the same reason for mutation
<chip> But mutation doesn't really work that way.
<allison> in the sense that mutation happens at a lower level than method calls?
<chip> if Cog isa Dog and isa Cat, and the Cat class knows how to morph into a HissingDemon, how can the Cog class permit that?  What does it become?
<chip> When you're composing to do MI, the whole odesn't mutate when the part does.  It subverts the composition in the first place.
<allison> in that case, the Cog doesn't want to inherit the mutation, so it overrides it
<chip> mutation isn't a thing to inherit.  It's like a print statement.  It can go anywhere based on arbitrary circumstances.  It's an action, not a property.
<allison> somewhere there is code that says "here's how you mutate a Cat into a HissingDemon"
<chip> well, yes, but the point I think I'm not being clear about is that there are several different mutations tha tmay all be possible, and their triggers can be arbitrary
<chip> "forbidden" and "allowed" are pretty much the only two mutation states I think a class has.  Once you allow it, I don't see that you'd want to be more specific
<chip> (because in some cases you probably can't)
<chip> cf. Perl 5 tie
<chip> BTW, you're way beyond normal end of meeting and I think I probably took enough time 
<chip> I do understand Perl 6 better and that can only bee good
<pmichaud> chip: I think we're very glad for any time you can take :-)
* chip grins ruefully
<chip> leo: Anything Parrot-internals-oriented you think I'm missing or misrepresenting?
<pmichaud> especially when dealing with a flaky net connection :)
<leo> nothing besides the already mentioned stuff
<chip> OK
<leo> well, a release name/number for the next one is a thing you could figure out in the next days
<chip> Well, I guess the answer is that the two models can't be reconciled in the same language, so we just have to enable both and let the users deal with the impedance mismatch in between.  Hopefully this won't make  C<use perl5::foo qw($bar); $bar++> impossible
<chip> leo: thanks for letting me take the easy one
<allison> I don't think it will be impossible
<allison> I think we're probably making it out to be harder than it really is
<chip> maybe so.  trying to see the crevasse before we fall in it, is all
<allison> (though there are some assumptions and consequences we need to think through)
<allison> yup
<allison> any other questions?
<leo> I'll be in Portugal around the first week of April, release will be before
<chip> neat.  leo++ releases
<allison> sounds like we're drawing to a close
<chip> a-firmative
<allison> thanks everybody, and talk to you next week!
<particle> cya
<leo> yeah - me's implementing some food in the meanwhile 
<chip> ciao
<leo> l8ter
% pmichaud has left #parrotsketch
% Coke has left #parrotsketch
% allison has left allison!~chatzilla@sub17-30.member.dsl-only.net
<audreyt> argh, missed the sketch :/
* audreyt is surprised to hear about "BigInt" being a class in P6 -- it's not mentioned anywhere.
<leo> audreyt: a bit ;)
<leo> audreyt: yep - that's what I've said
<audreyt> (well, alluded to in very very early A12, but not in synopses nor discussions)
<audreyt> I still think the one-bit-toggle between 31bit-int and BigInt is the correct way to go for Perl6 "Int"
<audreyt> at least that's the synopses's semantics.
<leo> that's an implementatio detail
<audreyt> the thing is that promotion wouldn't changge typeid.
<audreyt> otoh, the "BigInt does Int; int does Int" model doesn't quite make any sense :/
* audreyt is for complete elimination of morphing (under p6 context) -- but you already know that :)
<leo> yeah
<leo> its of courese strongly related to values and Str is slightly special
<leo> e.g. appending one char to a string of length 1M ...
<audreyt> how does morphing help here?
<leo> I've no troubles with Int/Num at all
<leo> not morphing but having immutable values
<leo> or mutable Strs in that case
<audreyt> but that's fine, as buflen allows sharing
<audreyt> (to a degree)
<audreyt> if you append 256+ bytes then it has to be realloced underneath
<audreyt> it's kinda similar to tuples
<leo> you think, strings within the alloced mem area can still be shared?
<leo> sounds like a plan in combination with COW
<audreyt> I don't see why not... it's just COW
<audreyt> yeah
<leo> ok - but that still is implementation detail & optimization - Q is: Str is an immutable value at P6 surface?
<audreyt> surely is
<audreyt> "moose"++
<audreyt> # dies
<leo> chip: ping ;)
<audreyt> chop("foo") # same
<leo> I think these facts are still well hidden in S*.pod
<audreyt> S09 stipulates that Str is intrinsically immutable
<audreyt> S02 says "List" is
<audreyt> (but lazily evaluated; "Tuple" is the fully evaluated form)
<audreyt> and all above are immutable
<leo> yeah, spread about several S* in at most one sentence
<audreyt> that's why we need Perl6::API :/
* audreyt will work on it next week in .jp
<leo> S02 should state that very clearly
* audreyt discovers that she has a commit bit to S02
<leo> but that might be a tradition in perldocs that it's utterly unclear, where what is doced ;)
<audreyt> heh indeed :)
* leo thinks that perldoc perlre is the first doc that is mentioning p5 string escapes ;)
<leo> (the first being that one, when you go through perldoc perl)
<audreyt> sleep - bbl :)
<leo> g nite
% leo has left leo!lt@feather.perl6.nl
% leo has joined #parrotsketch