Perl 6 Design Minutes for 14 January 2009

Nicholas:

• if I wanted PHP I know where to find it

Patrick:

• wasn't aware that .trim is not a Perl 5 built in

Larry:

• PHP has 3000+ functions, so we have a way to go yet
• seeking to strike the right balance

Larry:

• my question for the day "To what extent do unary hyperoperators descend into containers?" I think that they do, to some degree.
• also the exact definition of what .perl means.
• been doing a lot of thinking on that

Patrick:

• that's a good question to be thinking about, from a Rakudo implementor's position

Larry:

• that's why I might appear to be ignoring mailing lists

Patrick:

• can I .perl a sub?

Larry:

• you won't get the exact the same object back

Patrick:

• but a representation that compiles to the same sub?

Larry:

• I think it would be good if we could
• but at some point a lot of businesses are going to say "Oh, you just made it very easy to reverse engineer my sacred code".
• I don't think we can guarantee it, but whether it's strongly encouraged, but turn offable, or similar
• at least the types of code that are idempotent, or otherwise stateless such that they can be easily reconstituted
• in some ways we already have to be able to do that to save the state of the current language, as we have to save the current grammar and all the methods on it, to do prelude snapshots, or do an eval, without having to rebuild all from scratch
• I don't know where the balance point on that is

Patrick:

• sounds good. Aiming at the point I'm thinking of.

Larry:

• need to think about it
• do what's reasonable. not do doing something that will set the whole project back a whole year

Patrick:

• I mailed the list about pairs. Didn't spot a reply.
• if I iterate over a list of pairs, are the values of those pairs...?

Larry:

• those are references back to the original
• likewise pairs coming out of a hash should be references

Patrick:

• by "References" you meant the values, as the keys are immutable?

Larry:

• yes

Will:

• Tcl question
• for Parrot, I was going to have an attribute to save the high level source. It was going to return the text of the sub and let the user recompile it
• this is sane?

Patrick:

• I had that as a fallback, but wasn't what I really wanted to do

Larry:

• it's a good degenerate solution as a minimal solution that can serve as a backstop

Patrick:

• but that would mean that my PBC files would have the entire source code in them
• hence my question about .perl and subs was "Do we have to do that?"

Will:

• there's another language out there that needs to do that
• we could share infrastructure

Larry:

• you run into the Deparse problem
• what you see is after the optimiser got at the code
• it might be what you want, but it's not the original source

Jerry:

• is it possible that the spec could say that? The default is a sane default?

Patrick:

• you're forgetting that one of the Perl 6 mottoes is that it exists to torture implementation on behalf of the users

Larry:

• not so much that it never happens

Patrick:

• who defines that? I might have quit back in 2004.

Larry:

• with a rant preferably. :-)

Jerry:

• I've finished most of the technical details of S19. It needs a re-write. It doesn't read well.
• as far as a working copy goes (from my perspective, as the implementor) it's in a good place
• there may be some ambiguities, but I've moved onto the implementation
• next deliverable is a set of spec tests
• to implement them properly I'm building a test harness, so I'm coding before I can write the tests
• eager parsing, eager meaning .*?, as opposed to greedy, which would be .* behavior
• no one likes the terminology "eager"
• pulled it from S19
• didn't want to define something as non-greedy
• found "eager" in S5.

Larry:

• especially as in the rest of the language "eager" means "greedy"
• "frugal"?
• "parsimonious"?

Patrick:

• that was the term Mastering Regular Expressions uses
• lazy would be bad also
• yes, it's called Lazy

Larry:

• probably okay. Eager : Lazy :: Greedy : Parsimonious.
• that is how the rest of the language treats lists. "Eager" vs "Lazy".

Patrick:

• in the context of regular expressions, we'd call that ? qualifier lazy
• the association doesn't immediately come to me

Larry:

• it can be implemented with lazy lists. That's how Cursor.pm works.

Jerry:

• will take a stab at changing POD

Patrick:

• I'm going to be in S5, so I could

Larry:

• if Jeff Friedl uses that term too, that's good

Jerry:

• noticed that Larry weighed in on some issue relating to preludes that I'd mentioned in S19, so it looks like that part has been approved

Larry:

• well, I suggested it in the first place.
• I don't know if it makes *sense*. :-)
• maybe an alternate prelude doesn't make sense
• I don't think of preludes as actually preludes -- instead they're the surrounding lexical scope

Patrick:

• really we're waiting on the implementation so that we can see how it works in practice

Larry:

• I'm thinking of the same way an eval works
• the outer language is serving as a prelude for that eval
• it's the same thing, except that the current language can be frozen into the file, and then you're effectively starting up again from there

Patrick:

• it's layers, all the way down

Larry:

• well, all the way up

Patrick:

• the core compiler does an eval of the prelude, which brings a bunch of things into scope, which then does an eval of your code

Larry:

• it's more the parse of the eval. We use this to implement -n and -p
• it's not eval in the sense of recompiling each time through the loop.
• it's that eval does a sub-parse. That's what needs to be generalised
• Make good use of the ability to wrap compilations in one or more outer contexts. Whether we call it, prelude, or outer-lude
• what's the opposite of an interlude?

Jerry:

• environment variables also
• I considered a switch which let you set an environment variable
• this would let you do it on the same line for shells that don't provide such behavior

Larry:

• rn had one of those

Jerry:

• same as adding it in the prelude

Larry:

• except that environment variables are scoped dynamically
• another question about environment variables, which are essentially global
• can a dynamic scope override them?
• how easily within perl 6 code, just for that dynamic scope
• we speculated about connections between contextual variables and environment variables, or the globals

Jerry:

• I was under the impression that something was decided, and then changed

Larry:

• we can give that appearance :-)

Jesse:

• thank you everyone for the last few years. Enjoy your call next week.