Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> : then how would you assign undef to the only element of the LW> array? would this : be needed: LW> : LW> : @a = ( undef ) ;# same as p5? LW> : LW> : vs. LW> : @a = undef ;# like undef @a in p5? LW> Those would do the same thing under the current proposal, since LW> they're both in list context. If you really, really want a scalar LW> undef value in list context, you could always say LW> @a = scalar(undef); that works. i am starting to see what you mean by undef knowing about context. LW> : in fact i would like to LW> : stop allowing undef as a function with args and have it only return a LW> : scalar undef value. there should be a different op to truly make an LW> : aggregate undefined (and i still don't see a need for that, emptying it LW> : is all that i ever think is needed). LW> We could certainly split out a separate undefine() function. We could LW> even give it an optional argument that says *why* it's undefined, turning LW> it into an unthrown exception, basically. We could use such a function LW> to create interesting values of undef that are context sensitive. that split makes sense as you are now using undef as a special (or as you say below unexpected) value. so it shouldn't also be overloaded as a function operating on variables. just doing the split will make me happier (if you are so benevolent as to care about my happiness :). LW> : in my world undef is a scalar value and nothing else. how do you see it LW> : in p6? LW> undef is not a scalar value, it is the explicit *absence* of a value LW> where you expected one. In Perl 6, undef is the Bearer of Bad News. oy! i feel the pain of the late night phone call. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
On Sat, Mar 26, 2005 at 11:57:48PM -0500, Uri Guttman wrote: : > "LW" == Larry Wall <[EMAIL PROTECTED]> writes: : : LW> That being said, in Perl 5, if you say : : LW> @a = undef; : : LW> you don't get an undefined array. I'd like to make undef smart enough : LW> about list contexts that @a actually does end up undefined in Perl 6. : LW> That is, in scalar context, undef is a scalar value as in Perl 5, but : LW> in Perl 6, undef in list context means "there isn't anything here if : LW> you try to look for it", so it's more like () in Perl 5, except that : LW> it also undefines the array if it's the only thing in the array. : : then how would you assign undef to the only element of the array? would this : be needed: : : @a = ( undef ) ;# same as p5? : : vs. : @a = undef ;# like undef @a in p5? Those would do the same thing under the current proposal, since they're both in list context. If you really, really want a scalar undef value in list context, you could always say @a = scalar(undef); : i have always railed against undef on aggregates as it leads to using : defined on them which is not the same as checking if an aggregate has : any elements. i see that often in newbie code. Well, let's not confuse Perl 5's shortcomings with Perl 6's. I think we should fix the problem by making undef work a little more like the newbie expects, which is context dependent. : in fact i would like to : stop allowing undef as a function with args and have it only return a : scalar undef value. there should be a different op to truly make an : aggregate undefined (and i still don't see a need for that, emptying it : is all that i ever think is needed). We could certainly split out a separate undefine() function. We could even give it an optional argument that says *why* it's undefined, turning it into an unthrown exception, basically. We could use such a function to create interesting values of undef that are context sensitive. : in my world undef is a scalar value and nothing else. how do you see it : in p6? undef is not a scalar value, it is the explicit *absence* of a value where you expected one. In Perl 6, undef is the Bearer of Bad News. If you merely want undef for a scalar placeholder without negative connotations, I'd suggest something like class Empty {} my $nada = new Empty; instead. And $nada is the same length as undef. $X would be even shorter. On the other hand, Perl 6 is consistently returning booleans as 0 and 1 rather than "" and 1, so it's likely that constant 0 and 1 can be stored in "less than a bit", as it were. So there might even be some kind of zero type that's essentially a value that's always 0, and takes no room to store at all. That might serve as a pretty good neutral placeholder. Larry
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
On Sun, Mar 27, 2005 at 12:04:39AM -0500, Uri Guttman wrote: : > "LW" == Larry Wall <[EMAIL PROTECTED]> writes: : : LW> As I mentioned in my other message, I think we should not assume that : LW> Perl 6 works the same in this regard as Perl 5 does. There needs to be : LW> something we can return that not only means (), but means also means : LW> "You're hosed! (And here's why.)" And I think we can make undef mean : LW> that if we make it lazily sensitive to scalar/list context (much like @a : LW> itself can be lazily sensitive to context). : : LW> Hmm, maybe it would simpler to just tell everyone undef is a special empty : LW> lazy array that refuses to produce a value no matter how you ask. : : why use undef for the error code? Because there's usually a reason why the undef was created, and it would be useful for the user to learn that. : isn't this what exceptions are for? Undef is a form of unthrown exception. Throwing things is often too violent for fail-soft situation. : or setting $!? $! is the current unthrown exception in Perl 6. (Or actually, it's also the thrown exception inside a CATCH block.) : i actually use naked return as a postive thing in stem : (string return values are bad and have the error string. it is : consistant so it works). Okay, so in this case you could hack around the problem because you don't want to return interesting "good" values. But sometimes you have both interesting good values and interesting bad values. "Interesting" values of undef solves that problem without having to send either the good data or the bad data out of band. : the problem with returning undef (or naked : return) is that it is in-band data. now you could do a naked return but : error thing. and then the called has to check for that property each : time. You should be checking your return values anyway, or useing "fatal", which turns these unthrown exceptions into thrown ones. : but what does that mean when you do this (bad p6 code): : : sub return_error { return but error } That's written: sub return_error { fail "What went wrong" } which has the effect of sub return_error { return undef but Exception("What went wrong") } unless the caller uses "fatal", in which case it's more like sub return_error { die("What went wrong") } : my @a = return_error() ; : : is @a empty or what? how do you see the error in @a? I am proposing that assigning a exceptional undef value (such as that returned by fail() above) to an array causes the array to become undefined. If you use that array somewhere else, it's as if you used the original unthrown exception. Eventually you get caught trying to do something defined with the undefined value and you get a nice message out saying where the original undefined value came from. : i just don't like seeing undef used for error handling as it has too : many other uses (even if i did it in stem). I don't see how the proposed semantics interfere with any other uses of undef. A bare scalar undef is still a very simple value. I don't see how you can simultaneously argue that it has many uses and yet has only one simple value. : just make undef a scalar value and not a function nor a error marker. fail("Language designer not persuaded");# :-) Larry
Re: return of copies vs references
On Thu, Mar 17, 2005 at 07:21:18PM +0100, Thomas Sandlaß wrote: : Larry Wall wrote: : >That's actually weirdly symmetrical with the notion that only subs can : >impose compile-time context on their arguments, while methods always : >have to assume list context because you have to generate the argument : >list before you can know which method you're going to dispatch to. : : Sorry if it's only me, but I don't understand what this means. : : I get, that at the call site of a sub, first of all the lexically : closest sub can be determined at compile time. This means its signature : is available and can be checked and imposed on the arguments---right so far? Yes. : Single invocant methods are defined inside classes. Thus the knowledge : of the compiler about their signature hinges on how well the type : of the invocant can be determined. If the data is insufficient this : is---depending on compile mode---either a static type error or dynamic : lookup has to be compiled, with an optional warning. In general, most dynamic languages (including Perl 5) assume that it is impossible to know all the method names even after normal compilation, since new classes or methods can be added at any time. Perl 5 even lets you change your @ISA hierarchy on the fly, if you're willing to take the performance hit. : BTW, do method names have to be pre-declared? Or does the following just : defer the existence check: : : sub blubb ( $obj ) : { :print $obj.somemethod( "FirstArg", "SecondArg" ); : } : : What I want to ask is: is ".somemethod()" parsed purely syntactically? In standard Perl 6 this is pure syntax, and doesn't care whether .somemethod exists yet or not. : And is there a compiler mode where this is a type error like "type Any : doesn't have .somemethod"? Potentially it could, but it wouldn't by default. You'd have to explicitly tell the compiler that you aren't adding any more classes or methods. But then you couldn't use any kind of an autoloader, and plugable architectures become problematic. : With multi subs and methods I guess a lexical definition is needed as for : subs. But that doesn't mean that all dispatch targets are known already. : Thus a dynamic built-up of the arglist and MMD is compiled. Right? : A very nice feature of the compiler here were to perform implementation : side checks when the complete program is loaded? This involves potential : ambiguity and absence failures. For various definitions of "complete". Perl potentially runs a lot of code at compile time and compiles a lot of code at run time. : BTW, how far down to pure byte code can Perl6 packages be compiled? That would depend on your definition of "impure byte code", I expect. : Too much off the mark? Compile-time type checking is just another thing we're trying to make possible without actually doing it ourselves. But it's not way up there on the priority list. Larry
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> As I mentioned in my other message, I think we should not assume that LW> Perl 6 works the same in this regard as Perl 5 does. There needs to be LW> something we can return that not only means (), but means also means LW> "You're hosed! (And here's why.)" And I think we can make undef mean LW> that if we make it lazily sensitive to scalar/list context (much like @a LW> itself can be lazily sensitive to context). LW> Hmm, maybe it would simpler to just tell everyone undef is a special empty LW> lazy array that refuses to produce a value no matter how you ask. why use undef for the error code? isn't this what exceptions are for? or setting $!? i actually use naked return as a postive thing in stem (string return values are bad and have the error string. it is consistant so it works). the problem with returning undef (or naked return) is that it is in-band data. now you could do a naked return but error thing. and then the called has to check for that property each time. but what does that mean when you do this (bad p6 code): sub return_error { return but error } my @a = return_error() ; is @a empty or what? how do you see the error in @a? i just don't like seeing undef used for error handling as it has too many other uses (even if i did it in stem). just make undef a scalar value and not a function nor a error marker. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> That being said, in Perl 5, if you say LW> @a = undef; LW> you don't get an undefined array. I'd like to make undef smart enough LW> about list contexts that @a actually does end up undefined in Perl 6. LW> That is, in scalar context, undef is a scalar value as in Perl 5, but LW> in Perl 6, undef in list context means "there isn't anything here if LW> you try to look for it", so it's more like () in Perl 5, except that LW> it also undefines the array if it's the only thing in the array. then how would you assign undef to the only element of the array? would this be needed: @a = ( undef ) ;# same as p5? vs. @a = undef ;# like undef @a in p5? i have always railed against undef on aggregates as it leads to using defined on them which is not the same as checking if an aggregate has any elements. i see that often in newbie code. in fact i would like to stop allowing undef as a function with args and have it only return a scalar undef value. there should be a different op to truly make an aggregate undefined (and i still don't see a need for that, emptying it is all that i ever think is needed). in my world undef is a scalar value and nothing else. how do you see it in p6? uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: How could import constants from other modules?
On Fri, Mar 18, 2005 at 03:38:38PM +0800, song10 wrote: : hi, all : : is there any way to import constants from other modules without : specifying scope everytime? : such like this: : : module A; : use constant { PI => 3.14, VER => 1.1 } : ... : : : : module B; : my $var = A::PI; # this way is fine when A is 'short' or rare : : imagination : : module C; : use constant tag { PI => 3.14, VER => 1.1 } : ... : : : : module D; : use constant C::tag; : my $var = PI; # forgive my laziness I'm assuming that you want to write all those modules in one file without reimporting into every package. That's the default, since use will import into the lexical scope by default, so it will span all the packages. See http://dev.perl.org/perl6/synopsis/S11.html#Importation for more on that. On the other hand, your comment below leads me to believe that you might be asking for a way to do the same importation in separate files. It seems to me that you're asking for a "policy" module that imports on behalf of its user. I've said we will have policy modules, but we haven't defined a syntax for that yet. One way to do it would be for it to return a string to be evaluated as part of the compilation of the user's scope. That would be very powerful, but perhaps too powerful to be the default way of doing things. So, much like the distinction between text macros and "hygienic" macros, I'd like to see a way of providing a generic chunk of code to the using context either as raw text or as a precompiled hygienic code that has to be linked in as a form of generic code. We'd encourage people to use the templating approach over the textual approach because it's guaranteed to be syntactically correct, and makes it easier to keep track of where the code came from for debugging purposes. We already have to do something much like this to compose roles into classes. Roles are another form of generics. : is it a good idea to have header files and include pragma? : (sometimes, a big module file is also a headache. having this : feature, we could split it up.) When I see what a mess C and C++ get into with textual inclusion, I am hesitant to make the same mistake in Perl. I think we'll make it possible, but we'll try to make it easier to write hygienic policy modules instead. Larry
Re: String Theory
On Fri, Mar 25, 2005 at 07:38:10PM -, Chip Salzenberg wrote: : Would this be a good time to ask for explanation for C being : never Unicode, while C is always Unicode, thus leading to an : inability to box a non-Unicode string? As Rod said, "str" is just a way of declaring a byte buffer, for which "characters", "graphemes", "codepoints", and "bytes" all mean the same thing. Conversion or coercion to more abstract types must be specified explicitly. : And might I also ask why in Perl 6 (if not Parrot) there seems to be : no type support for strings with known encodings which are not subsets : of Unicode? Well, because the main point of Unicode is that there *are* no encodings that cannot be considered subsets of Unicode. Perl 6 considers itself to have abstract Unicode semantics regardless of the underlying representation of the data, which could be Latin-1 or Big5 or UTF-76. That being said, abstract Unicode itself has varying levels of abstraction, which is how we end up with .codes, .graphs, and .chars in addition to .bytes. Larry
Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]
On Sat, Mar 26, 2005 at 02:37:24PM -0600, Rod Adams wrote: : Larry Wall wrote: : : >%+ and %- are gone. $0, $1, $2, etc. are all objects that know : >where they .start and .end. (Mind you, those methods return magical : >positions that are Unicode level independent.) : > : How can you have a level independent position? By not confusing positions with numbers. They're just pointers into a particular string. : The matching itself happens at a specified level. (Note that which level : the match happens at can change what is matched.) So it makes sense that : all the positions that come out of it are in terms of that level. When we're dealing with mostly variable length encodings, it makes more sense that the positions come out as string pointers that only convert to numbers grudgingly under duress. If you're just going to feed a position back into a substr() or as the start position of the next index(), there's no reason to translate it to a number and back to a pointer. It's a lot more efficient if you don't. : Now, that position can be translated to a lower level, but not to an : upper level, since you can happily land in the middle of a char. I talked about this problem in one of the As. I think the fail soft approach is to round to the next "ceiling" boundary and issue a warning. : This is part of what I'm having trouble with your concept of a Str being : at several levels at once: There's no reliable way to have a notion of : "position", expect to have it as attached to the highest possible level, : and the second someone does something at lower level, you void the : position, and possibly the ability to remain at that high level. A position that is a pointer can be true for all levels simultaneously. It has the additional benefit of a type that is subtype constrained to operate with other values from the same string, so if you subtract two pointers from different strings, you can actually detect the error. : I still see my notion of a Str having only one level and encoding at a : time as being preferable. Having the ability to recast a string to other : levels/encoding should be easy, and many builtins should do that : recasting for you. And I still see that you can have your view if you install a pragma that forces all incoming strings to a single level. But I think we can do that lazily, or not at all, in many cases. The basic underlying problem is that there is no simple mapping from math to Unicode. The language that lets people express their solution in terms of Unicode instead of in terms of math is going to have a leg up on the future, at least in the Unicode problem space. Strings were never arrays in Perl, and they're only getting further apart as the world makes greater demands on strings to represent human language. So I'd much rather introduce an abstraction like "string position" now that is not a number. It's a dimensional value, where the scaling of the dimensionality is bound to a particular string. You can have a pragma that says, "Untyped numbers are assumed to be meters, kilograms, and seconds", and a different lexical scope might have a pragma that says "Untyped numbers are assumed to be centimeters, grams, and seconds." These scopes can get along as long as they don't try to exchange untyped integers. Or if they do, they have some way of ascertaining what an untyped integer meant when it was generated. : I do _not_ see $/ & friends getting ported across a recasting. .pos can : be translated if new level <= old level, otherwise gets set to undef. The interesting thing about a pointer is that you can pass it through a higher level transparently as long as you don't actually try to use it. But if you do try to use it, I think undef is overkill. Just as a float stuffed into an int truncates, we should just pick a direction to find the next boundary and go from there, maybe with a loss of precision warning. The right way to suppress the warning would be to install an explicit function that rounds up or down. : Please convince me your view works in practice. I'm not seeing it work : well when I attempt to define the relevent parts of S29. But I might : just be dense on this. Well, let's work through an example. multi method substr(Str $s: Ptr $start, PtrDiff ?$len, Str ?$repl) Depending on the typology of Ptr and PtrDiff, we can either coerce various dimensionalities into an appropriate Ptr and PtrDiff type within those classes, or we could rely on MMD to dispatch to a suite of substr implementations with more explicit classes. Interestingly, since Ptrs aren't integers, we might also allow multi method substr(Str $s: Ptr $start, Ptr ?$end, Str ?$repl) which might be a more natural way to deal with variable length encodings, and we just leave the "lengthy" version in there for old times sake. We could go as far as to allow a range as the second argument: $x = substr($a, $start..^$end); or its evil twin: $x = $a[$start..^$
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
On Sat, Mar 26, 2005 at 03:13:07AM -0700, Luke Palmer wrote: : Chip Salzenberg writes: : > I'm working on enhancing Perl6::Subs[*] to support more parameter : > traits than just C. I have some questions about : > parameters and traits. (These questions all apply to pure Perl 6, : > which I know I won't be able to translate completely, but I want to : > know which target I'm missing.) : > : > * Given a parameter C, it's obvious I'm not allowed to : >C, because I didn't say C. But am I allowed to : >C<@a[0]++>? How about C<@a[0][0]++>? How deep is read-only-ness? : : I believe that the default constant parameters is so we don't have to : construct lvalues out of our arguments when we call. So that probably : means that it's very shallow. : : On the language level, I've been thinking that it would be good to go : C's way and not allow any parameter modification whatsoever. The : problem is that in the presence of methods, we can't tell whether we : have to lvaluize anymore, so we're back to the Perl 5 trap of lvaluizing : everything. I think only predeclared simple subs are allowed to have "rw" parameters. Methods can have "is ref" parameters, but those don't require enforced lvaluehood on the caller end like rw does. : So if you want things modified, you'd have to pass in a reference. : Arrays and hashes would not generally have this restriction, since we : pass references of those guys anyway. Yes. : > * Similarly, how deep is the copy implied by C? : : I think it's exactly as deep as read-only-ness. And both may be exactly as deep as COW. : > * Do traits attach syntactically to the variable name, or to the : >declaration as a whole? : > : > variable: @a is rw of Array : >Array @a is rw : > : > declaration: @a of Array is rw : >Array @a is rw : : Well, from this example it seems like `of` should be tighter than `is`. Traits are not allowed on ordinary rvalues, only on declarations. "is" traits always attach to the main declaration. "of" types always attach to the container on their immediate left. : > * As far as I can tell, the choice of spelling an array parameter : >C or C is entirely cosmetic: both @a and : >$a are capable of holding an Array reference. Is there actually : >a difference, e.g. in how they handle an undefined value? : : Hmmm... well I think all scalars are allowed to be undef. Arrays : aren't. So yeah, if you give @a undef, it probably gives you [] (or : croaks, but I don't think that's a good idea). If you give $a undef, it : gives you undef. As I mentioned in my other message, I think we should not assume that Perl 6 works the same in this regard as Perl 5 does. There needs to be something we can return that not only means (), but means also means "You're hosed! (And here's why.)" And I think we can make undef mean that if we make it lazily sensitive to scalar/list context (much like @a itself can be lazily sensitive to context). Hmm, maybe it would simpler to just tell everyone undef is a special empty lazy array that refuses to produce a value no matter how you ask. Larry
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
On Sat, Mar 26, 2005 at 03:45:30PM -0500, Chip Salzenberg wrote: : According to Rod Adams: : > Chip Salzenberg wrote: : > >* As far as I can tell, the choice of spelling an array parameter : > > C or C is entirely cosmetic: both @a and : > > $a are capable of holding an Array reference. Is there actually : > > a difference, e.g. in how they handle an undefined value? : > : > Uhm... It was my impression that one of those creates an Array of : > Arrays, and the other just an Array. : : Ah, my question had a bug. What I meant was: : : * As far as I can tell, the choice of spelling an array parameter :C<@a> or C is entirely cosmetic: both @a and $a are :capable of holding an Array reference. Is there actually a :difference, e.g. in how they handle an undefined value? Not really. The main difference is that @a will flatten in a list context, and $a won't. That being said, in Perl 5, if you say @a = undef; you don't get an undefined array. I'd like to make undef smart enough about list contexts that @a actually does end up undefined in Perl 6. That is, in scalar context, undef is a scalar value as in Perl 5, but in Perl 6, undef in list context means "there isn't anything here if you try to look for it", so it's more like () in Perl 5, except that it also undefines the array if it's the only thing in the array. I don't know if that's an entirely consistent semantics, but I'd rather have a little inconsistency and preserve error informaiton for later debugging whenever possible, and that undef you tried to initialize the array with might have some interesting commentary in it. (Though, of course, my example above is a rather boring value of undef.) Larry
Re: [Fwd: Re: Moving the p5 standard library to p6]
On Sat, Mar 26, 2005 at 11:31:07AM +0100, Juerd wrote: : Perhaps good administration would be to introduce a generic Deprecated:: : namespace. Module authors can move their own old modules there if they : want, and there can be Deprecated::P5 for stuff like dbmopen, : Deprecated::Perl5::File::Find. : : Deprecated::Perl5 could export everything it has to Deprecated, with a : symbol group ("tag"), so you can : : use Deprecated :perl5; : : and even : : use Deprecated :all; : : And Perl can have built-in warnings, as one huge refactoring of all : those warnings you'd otherwise have. The 'deprecated' category should : warn for use of any symbol in Deprecated::. : : use warnings :deprecated; : no warnings :deprecated; : : (Explicit 'use Deprecated' would export symbols, and because then the : symbols are used from ::, no warning is emited.) Maybe I'm just being dense, but I don't see any particular reason to make it easy to use deprecated features en masse. If they want a Ponie, they want a whole Ponie, and not large chunks of a Ponie. Larry
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
According to Rod Adams: > Chip Salzenberg wrote: > >* As far as I can tell, the choice of spelling an array parameter > > C or C is entirely cosmetic: both @a and > > $a are capable of holding an Array reference. Is there actually > > a difference, e.g. in how they handle an undefined value? > > Uhm... It was my impression that one of those creates an Array of > Arrays, and the other just an Array. Ah, my question had a bug. What I meant was: * As far as I can tell, the choice of spelling an array parameter C<@a> or C is entirely cosmetic: both @a and $a are capable of holding an Array reference. Is there actually a difference, e.g. in how they handle an undefined value? -- Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]> Open Source is not an excuse to write fun code then leave the actual work to others.
Perl5->P6 convertor as refactoring tool
On Sat, Mar 26, 2005 at 10:13:54AM -0800, Larry Wall wrote: > The thing is that these MAD props are hung on whatever node is handy > at the time, [...]. That's the main reason for the first pass of > translator, to reattach the madprops at a more appropriate place in > the tree. > [...] > But with comments you'd like them > to travel with the code they're commenting, in cases where refactoring > moves code around. So, what I'm hearing you say is that you have just written the very very basic skeleton--maybe even just the backbone--of a Perl refactoring browser. Is that correct? Once you're done, could the community take this tool that you're producing and flesh it out into something that would allow for straightforward refactoring and reformatting of Perl code? --Dks
Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]
On Sat, 2005-03-26 at 12:48 -0800, Larry Wall wrote: > On Sat, Mar 26, 2005 at 09:59:10AM -0500, Aaron Sherman wrote: > Well, there is a process object, but it actually exists inside the > operating system. It's a little silly to force people to name their > own process all the time. I think we can assume that global variables > belong to the current process, sort of on the "you're soaking in it" > principle. That seems to be a self-limiting position. It leads (as it did in Perl 5) to a desire to reduce the number of times you add access to new OS features (as it requires global namespace suckage, though not as bad as in Perl 5), and you'll still split out an object, module or data structure to contain all of the information that's not in Perl proper because it's platform specific (e.g. current drive letter context under DOS). I agree that $*PID is a useful alias for $*PROC.pid (though the extra * still bothers me), but providing a unified API for interacting with myself as an OS-level construct seems to make sense. That's perhaps just my preference. I'm a hybrid OO/procedural guy, so I tend to reach into the OO toolbox whenever I think it will make my life easier. > : If you think of the OS-level shell around a Perl interpreter as an > : object[...] > We can certainly have various objects proxying for various contexts. > It's not clear how those should be broken out though. To me, an OS > isn't a process, and there's not necessarily going to be a one-to-one > correspondence. True enough, and you would certainly NOT: my $sock = $*PROC.socket; That makes no sense at all. However, things like "what IO layer am I using" or "am I a thread" are perfectly valid questions to pose of a process abstraction. > : If we consider $*PROC to be the invocant of the implicit "main", then: > : > : say "I am number {.pid}, who is number 1?"; > That's an interesting idea, the more so now that we're leaning away > from .foo ever assuming the current topic unless it also happens to > be the invocant. But it probably wouldn't do to have one common name for > the .pid outside of methods and force people to use a different name > inside methods. Here's where $*PID works much better, because it can > be the same everywhere. Well, it's always: $*PROC.pid The invocant goodness is just handy in a certain circumstance (what *is* main's invocant, out of curiosity? I guess it could be the interpreter context, but that should probably have some relationship to your process info anyway (either is or does ... probably does.) If I were writing Learning Perl 6, I would teach "$*PID" and/or "$*PROC.pid", but not ".pid".
Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]
On Sat, Mar 26, 2005 at 09:59:10AM -0500, Aaron Sherman wrote: : On Sat, 2005-03-26 at 00:27 -0800, Larry Wall wrote: : : > $$ is now $*PID. ($$foo is now unambuous.) : > : > $0 is gone in favor of $*PROGRAM_NAME or some such. : : You know, Java did one thing in this respect that I liked, and managed : to do it in a way that I couldn't stand. The idea of program as object : was nice, but they made the programmer manage it, which was really kind : of silly. Well, there is a process object, but it actually exists inside the operating system. It's a little silly to force people to name their own process all the time. I think we can assume that global variables belong to the current process, sort of on the "you're soaking in it" principle. : If you think of the OS-level shell around a Perl interpreter as an : object, and make perl manage that for you, then this falls out rather : nicely: : : $*PID := $*PROC.pid; : $*PPID := $*PROC.ppid; : $*PROGRAM_NAME := ~$*PROC; : : Perhaps even some often-used data could be shoved in there: : : $life = time() - $*PROC.start_time; : : In fact, it seems like a good place for any OS-level globals: : : $*IN := $*PROC.pio_in // $*PROC.stdin; We can certainly have various objects proxying for various contexts. It's not clear how those should be broken out though. To me, an OS isn't a process, and there's not necessarily going to be a one-to-one correspondence. : If we consider $*PROC to be the invocant of the implicit "main", then: : : say "I am number {.pid}, who is number 1?"; : : works just fine in global context. This also gives you a nice simple way : to drill down into your interpreter / runtime / VM / whatever state: : : say "I'm {.name} running under {.interp.name}"; That's an interesting idea, the more so now that we're leaning away from .foo ever assuming the current topic unless it also happens to be the invocant. But it probably wouldn't do to have one common name for the .pid outside of methods and force people to use a different name inside methods. Here's where $*PID works much better, because it can be the same everywhere. Larry
Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]
Larry Wall wrote: %+ and %- are gone. $0, $1, $2, etc. are all objects that know where they .start and .end. (Mind you, those methods return magical positions that are Unicode level independent.) How can you have a level independent position? The matching itself happens at a specified level. (Note that which level the match happens at can change what is matched.) So it makes sense that all the positions that come out of it are in terms of that level. Now, that position can be translated to a lower level, but not to an upper level, since you can happily land in the middle of a char. This is part of what I'm having trouble with your concept of a Str being at several levels at once: There's no reliable way to have a notion of "position", expect to have it as attached to the highest possible level, and the second someone does something at lower level, you void the position, and possibly the ability to remain at that high level. I still see my notion of a Str having only one level and encoding at a time as being preferable. Having the ability to recast a string to other levels/encoding should be easy, and many builtins should do that recasting for you. I do _not_ see $/ & friends getting ported across a recasting. .pos can be translated if new level <= old level, otherwise gets set to undef. Please convince me your view works in practice. I'm not seeing it work well when I attempt to define the relevent parts of S29. But I might just be dense on this. -- Rod Adams
Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]
On Sat, Mar 26, 2005 at 03:37:41AM -0700, Luke Palmer wrote: : > $! will be a legal variable name. $/ is going away, : : By which you mean that $/ is turning into a special $0. I'd say that $0 is a specialization of $/, but yes, basically, they both represent the current match result, albeit differently. $0 is explicitly what would have been returned by $1 if you'd put parens around the entire match, which is not quite the same as the complete match. result. : > Anything that varied with the selected output filehandle like $| : > is now a method on that filehande, and the variables don't exist. : > (The p5-to-p6 translator will probably end up depending on some : > $Perl5ish::selected_output_filehandle variable to emulate Perl 5's : > single-arg select().) : : I think $| et al. could just translate to methods on $*OUT, and select : would look like this: : : sub perl5_select($fh) { : $*OUT = $fh; : } : : Is there some subtlety that that doesn't cover? Like, it renders standard output nameless? In Perl 5, the selected output handle is a level of indirection above the standard names for the streams attached to fd 0, 1, and 2. Saying select(FH) doesn't change the meaning of STDOUT. : > %+ and %- are gone. $0, $1, $2, etc. are all objects that know : > where they .start and .end. (Mind you, those methods return magical : > positions that are Unicode level independent.) : : Uh, it might be a bad idea to make $# objects. It might not, but it : might. I think it would be fine if they turned into regular strings : upon assignment (and to pass their full objecthood around, you'd have to : backwhack them). But the problem with keeping them objects is that if : you put them somewhere else and change them, they turn back into regular : strings without .start and .end, which may be a hard-to-track-down bug : if you're thinking that they stay objects... haven't really thought : about this much (and my head is irritatingly foggy at the moment). My head is always irritatingly foggy. :-) Anyway, I'm think of them more as COW objects, and they'd have to know if their original string was yanked out from under them in any case, so that's probably the correct moment to invalidate .start and .end, if we even bother. : > $; is gone because the multidim hash hack is gone. : : Funny, I never used the multidim hash hack, I just emulated it: : : $hash{"$foo$;$bar"} = $value; Well, guess how we'll emulate it in Perl 6. :-) : > We never did find a use for $}, thank goodness. : : Isn't that the "enable all of Damian's unpublished modules" variable? Shh. Impressionable people are listening. : > $^W is is too blunt an instrument even in Perl 5, so it's probably gone. : : Well, almost. When writing a recent module, I found that one of the : modules I was using was spitting out an error from its own internal code : on one of my calls, and there was nothing wrong with the call. I : submitted a bug report to the author, and searched for a way to shut it : up so my users wouldn't complain at me. It ended up having to use $^W : at compile time (and it looks very hackish). We ought to have a : (perhaps not quite as hackish) ability to say "there's no reason for : that warning, but I can't modify your code, so just be quiet". Yes, we need to be able to suppress warnings in dynamic scopes as well as lexical, but that's probably not a scalar proposition anymore, unless the replacement for $^W is taken as a pointer to a hash of potential warnings. Presumably you could temporize the whole hash to suppress all warnings, or individual elements to suppress individual warnings. But maybe that's a good place for temporized methods instead, and then we could name sets of warnings. Or maybe there's yet some other approach that makes more sense. We want to encourage people to suppress only the exact warnings they want to suppress, and not just cudgel other modules into silence. : > I'm not quite sure what to do with $^N or $^R yet. Most likely they : > end up as something $ish, if they stay. : : For $^N, how about $/[-1]? I guess that makes some sense. I was thinking of $/[-$n] as relative to the current match position, but hadn't thought it through to the point of deciding how to count those. $^N mandates counting based on right parentheses rather than left, which I guess makes sense. So let's say that $/[-2] means (one) rather the incomplete ((three)two): /(one)((three) { $/[-2] } two) I note that this is another difference between $/ and $0, since $/ is representing the current state of the match, while $0 isn't bound till the match succeeds (unless you explicitly bind it earlier, which is yet another difference between $0 and $/, since you can't bind $/ to mean a portion of itself). Larry
Re: String Theory
Chip Salzenberg wrote: Would this be a good time to ask for explanation for C being never Unicode, while C is always Unicode, thus leading to an inability to box a non-Unicode string? That's not quite it. C is a forced Unicode level of "Bytes", with encoding "raw", which happens to not have any Unicode semantics attached to it. And might I also ask why in Perl 6 (if not Parrot) there seems to be no type support for strings with known encodings which are not subsets of Unicode? There are two different things to consider at the P6 level: Unicode level, and encoding. Level is one of Bytes, CodePoints, Graphemes, or Language Dependent Characters (aka LChars aka Chars). It's the way of determining what a "character" means. This can all get a bit confusing for people who only speak English, since our language happens to map nicely into all the levels at once, with no "merging of multiple code points into a grapheme" monkey business. Encoding is how a particular string gets mapped into bits. I see P6 as needing to support all the common encodings (raw, ASCII, UTF\d+[be|le]?, UCS\d+) "out of the box", but then allowing the user to add more as they see fit (EBCDIC, etc). Level and Encoding can be mixed and matched independently, except for the combos that don't make any sense. -- Rod Adams
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
Chip Salzenberg wrote: * As far as I can tell, the choice of spelling an array parameter C or C is entirely cosmetic: both @a and $a are capable of holding an Array reference. Is there actually a difference, e.g. in how they handle an undefined value? Uhm... It was my impression that one of those creates an Array of Arrays, and the other just an Array. In other words, using @ instead of $ puts a "Array of" in front of the supplied type. This makes sense when one considers orthogonality with C and C. But it's easy to get tripped up it. -- Rod Adams (Who needs more days in the week, so he can continue work on S29).
Re: PPI and the Perl 5 to Perl 6 converter?
On Sat, Mar 26, 2005 at 06:49:58PM +1100, Adam Kennedy wrote: : >Er, I'm not sure you will want to--I'm using PPI's evil twin brother, : >"PPD" (the actual Perl parser). I've just modified it so it doesn't : >forget anything I want it to remember. (As you know, the standard : >parser throws away gobs of useful information, everything from : >whitespace and comments to pruned opcode subtrees. I have a version : >that doesn't do that, by and large, though I'm still finding fiddly : >spots.) : : So I'm presuming that you don't intend this as a tool that can do mass : porting of code (due to the dependency issues), but rather as something : for helping individual module authors port individual files/modules. With the existence of Ponie, my hope is that people can port things piecemeal and retest for regressions at every stage along the way, presuming they have something that actually has regression tests. I think "translate everything and hope for the best" is a recipe for disaster on any project larger than one person's head. That being said, there's nothing that says the translator has to support only one kind of output, which means there's no reason you can't have some kind of overall policy driving the individual translations, so I don't see why dependency mapping should be a big problem. It just forces your translation granularity to chunks of modules that require the same support, when that support is of a nature that can't be split between Ponie and Perl 6. Only in the limit does that mean you have to translate everything all at once, and you'd still probably want some kind of overall policy file to control it, if only so you can tweak it and try the whole mess some other way. : Also curious how you handle BEGIN and friends... I take they are : executed and then pruned, and end up unpruned in your XML? I just intercept the op_free() routine with another routine that knows where to store the op tree that was about to be freed, to the first approximation. I also install null nodes in the tree as "pegs" to hang the exact location of declarations like BEGIN, use, subs, etc. : Also curious if you have managed to keep comments, POD etc... Certainly. It takes MAD skills, where MAD stands for Miscellaneous Attribute Decorations. (Doing anything with toke.c requires madness.) Well, actually, speaking of doing things piecemeal, I haven't tested the POD part yet, just the comments. And I'm quite sure I haven't captured the __DATA__ yet, but that'll have to happen too. But conceptually it's all there. :-) The thing is that these MAD props are hung on whatever node is handy at the time, which might be the token before, but usually is the token after, but usually *wants* to be somewhere up higher in the tree that doesn't exist yet. The changes to Perl internals are intentionally very minimal so as not to influence parsing behavior more than .5 iota, so I don't try to do any tree rearrangement in the parser. The XML is just the raw dump of the tree with its misplaced madprops. That's the main reason for the first pass of translator, to reattach the madprops at a more appropriate place in the tree. Interesting issues arise, such as deciding when a comment goes with the previous code and when it goes with the next code, or when you just stick it into the interstices for now. At the moment my tendency is to hoist leading and trailing whitespace into the interstices of the higher list when that's practical. But with comments you'd like them to travel with the code they're commenting, in cases where refactoring moves code around. The basic problem is that there's no one level that's right to do the translation. You have to take into account both shallow and deep information and everything in between simultaneously, because all of those things are important to the programmer at some point. I'm aiming for a deeply correct translation that tries to preserve as much surface detail as possible, but when push comes to shove, it's the surface detail that has to get shoved, even if that screws up their pretty formatting. The nice thing about a deep translation is that you can know when you're guessing, and at least mark it so the programmer can double-check the translation. A surface-level translator is always guessing, and doesn't always know it. I dare say most Perl 5 could be translated to Perl 6 with a series of s///, but it always be getting stupid just when you want it to be smart. Gee, it looks like you found my hot button, or at least my warm button. Maybe I should work up a talk about all this someday... Larry
Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]
On Sat, 2005-03-26 at 00:27 -0800, Larry Wall wrote: > $$ is now $*PID. ($$foo is now unambuous.) > > $0 is gone in favor of $*PROGRAM_NAME or some such. You know, Java did one thing in this respect that I liked, and managed to do it in a way that I couldn't stand. The idea of program as object was nice, but they made the programmer manage it, which was really kind of silly. If you think of the OS-level shell around a Perl interpreter as an object, and make perl manage that for you, then this falls out rather nicely: $*PID := $*PROC.pid; $*PPID := $*PROC.ppid; $*PROGRAM_NAME := ~$*PROC; Perhaps even some often-used data could be shoved in there: $life = time() - $*PROC.start_time; In fact, it seems like a good place for any OS-level globals: $*IN := $*PROC.pio_in // $*PROC.stdin; If we consider $*PROC to be the invocant of the implicit "main", then: say "I am number {.pid}, who is number 1?"; works just fine in global context. This also gives you a nice simple way to drill down into your interpreter / runtime / VM / whatever state: say "I'm {.name} running under {.interp.name}";
Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]
Larry Wall creates Sish28: > On Sat, Mar 26, 2005 at 02:11:29PM +0800, Autrijus Tang wrote: > : On Fri, Mar 25, 2005 at 10:03:45PM -0800, Larry Wall wrote: > : > Hmm, well, if it got that far. Given strict being on by default, > : > this particular example should probably just die on the fact that $" > : > isn't declared, since there's no $" in Perl 6. > : > : Is $" okay as a variable name? Is everything from perlvar.pod legal? :) > > Considering nobody's written perlvar.pod for Perl 6 yet, yeah, everything > in that pod is legal. :-) > > : my $" = 3; > : > : Pugs parses that because it only considers $! and $/ as legal > : symbolic variable names. > > $! will be a legal variable name. $/ is going away, By which you mean that $/ is turning into a special $0. > Anything that varied with the selected output filehandle like $| > is now a method on that filehande, and the variables don't exist. > (The p5-to-p6 translator will probably end up depending on some > $Perl5ish::selected_output_filehandle variable to emulate Perl 5's > single-arg select().) I think $| et al. could just translate to methods on $*OUT, and select would look like this: sub perl5_select($fh) { $*OUT = $fh; } Is there some subtlety that that doesn't cover? > %+ and %- are gone. $0, $1, $2, etc. are all objects that know > where they .start and .end. (Mind you, those methods return magical > positions that are Unicode level independent.) Uh, it might be a bad idea to make $# objects. It might not, but it might. I think it would be fine if they turned into regular strings upon assignment (and to pass their full objecthood around, you'd have to backwhack them). But the problem with keeping them objects is that if you put them somewhere else and change them, they turn back into regular strings without .start and .end, which may be a hard-to-track-down bug if you're thinking that they stay objects... haven't really thought about this much (and my head is irritatingly foggy at the moment). > $; is gone because the multidim hash hack is gone. Funny, I never used the multidim hash hack, I just emulated it: $hash{"$foo$;$bar"} = $value; > We never did find a use for $}, thank goodness. Isn't that the "enable all of Damian's unpublished modules" variable? > $^W is is too blunt an instrument even in Perl 5, so it's probably gone. Well, almost. When writing a recent module, I found that one of the modules I was using was spitting out an error from its own internal code on one of my calls, and there was nothing wrong with the call. I submitted a bug report to the author, and searched for a way to shut it up so my users wouldn't complain at me. It ended up having to use $^W at compile time (and it looks very hackish). We ought to have a (perhaps not quite as hackish) ability to say "there's no reason for that warning, but I can't modify your code, so just be quiet". > I'm not quite sure what to do with $^N or $^R yet. Most likely they > end up as something $ish, if they stay. For $^N, how about $/[-1]? Luke
Re: [Fwd: Re: Moving the p5 standard library to p6]
chromatic skribis 2005-03-26 2:13 (-0800): > No. Please, no. :) > As I see it, Perl 6 has a chance to start over with a very small set of > core libraries -- perhaps embarrassingly small -- so as not to entomb > our current, potentially-blepharitic guesses at good Perl 6 design > principles for the next twenty years or so. > If people really want File::Find or MakeMaker interface compatibility in > Perl 6, I suggest a new top-level namespace, namely > GodHelpYou::File::Find, though P5Compat may be less exciting and more > appropriate. Perhaps good administration would be to introduce a generic Deprecated:: namespace. Module authors can move their own old modules there if they want, and there can be Deprecated::P5 for stuff like dbmopen, Deprecated::Perl5::File::Find. Deprecated::Perl5 could export everything it has to Deprecated, with a symbol group ("tag"), so you can use Deprecated :perl5; and even use Deprecated :all; And Perl can have built-in warnings, as one huge refactoring of all those warnings you'd otherwise have. The 'deprecated' category should warn for use of any symbol in Deprecated::. use warnings :deprecated; no warnings :deprecated; (Explicit 'use Deprecated' would export symbols, and because then the symbols are used from ::, no warning is emited.) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
[Fwd: Re: Moving the p5 standard library to p6]
Forwarded... On Sat, 2005-03-26 at 12:05 +1100, Andrew Savige wrote: > Please note that I am not an expert on any of this, I was just > wondering whether we are going to clean up the old p5 library > interfaces as part of the move to p6. Or must we support the > old p5 library interfaces for backwards compatibility? No. Please, no. :) As I see it, Perl 6 has a chance to start over with a very small set of core libraries -- perhaps embarrassingly small -- so as not to entomb our current, potentially-blepharitic guesses at good Perl 6 design principles for the next twenty years or so. If people really want File::Find or MakeMaker interface compatibility in Perl 6, I suggest a new top-level namespace, namely GodHelpYou::File::Find, though P5Compat may be less exciting and more appropriate. -- c
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
Chip Salzenberg writes: > I'm working on enhancing Perl6::Subs[*] to support more parameter > traits than just C. I have some questions about > parameters and traits. (These questions all apply to pure Perl 6, > which I know I won't be able to translate completely, but I want to > know which target I'm missing.) > > * Given a parameter C, it's obvious I'm not allowed to >C, because I didn't say C. But am I allowed to >C<@a[0]++>? How about C<@a[0][0]++>? How deep is read-only-ness? I believe that the default constant parameters is so we don't have to construct lvalues out of our arguments when we call. So that probably means that it's very shallow. On the language level, I've been thinking that it would be good to go C's way and not allow any parameter modification whatsoever. The problem is that in the presence of methods, we can't tell whether we have to lvaluize anymore, so we're back to the Perl 5 trap of lvaluizing everything. So if you want things modified, you'd have to pass in a reference. Arrays and hashes would not generally have this restriction, since we pass references of those guys anyway. > * Similarly, how deep is the copy implied by C? I think it's exactly as deep as read-only-ness. > * Do traits attach syntactically to the variable name, or to the >declaration as a whole? > > variable: @a is rw of Array >Array @a is rw > > declaration: @a of Array is rw >Array @a is rw Well, from this example it seems like `of` should be tighter than `is`. > * As far as I can tell, the choice of spelling an array parameter >C or C is entirely cosmetic: both @a and >$a are capable of holding an Array reference. Is there actually >a difference, e.g. in how they handle an undefined value? Hmmm... well I think all scalars are allowed to be undef. Arrays aren't. So yeah, if you give @a undef, it probably gives you [] (or croaks, but I don't think that's a good idea). If you give $a undef, it gives you undef. > [*] Shameless Plug: Perl6::Subs is a source filter that lets you use > much of the Perl 6 parameter syntax in your Perl 5 programs; and > it enforces many constraints for you. You can even add your own > constraints with C subtyping. Amaze your enemies! > Confound your friends! Use Perl6::Subs today! Cool. Luke
Re: PPI and the Perl 5 to Perl 6 converter?
Er, I'm not sure you will want to--I'm using PPI's evil twin brother, "PPD" (the actual Perl parser). I've just modified it so it doesn't forget anything I want it to remember. (As you know, the standard parser throws away gobs of useful information, everything from whitespace and comments to pruned opcode subtrees. I have a version that doesn't do that, by and large, though I'm still finding fiddly spots.) So I'm presuming that you don't intend this as a tool that can do mass porting of code (due to the dependency issues), but rather as something for helping individual module authors port individual files/modules. Also curious how you handle BEGIN and friends... I take they are executed and then pruned, and end up unpruned in your XML? Also curious if you have managed to keep comments, POD etc... Adam K
Re: String Theory
Would this be a good time to ask for explanation for C being never Unicode, while C is always Unicode, thus leading to an inability to box a non-Unicode string? And might I also ask why in Perl 6 (if not Parrot) there seems to be no type support for strings with known encodings which are not subsets of Unicode? If the explanations are "you have greatly misunderstood the contents of Synopsis $foo", I will happily retire to my reading room. -- Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]> "What I cannot create, I do not understand." - Richard Feynman
Parameter and trait questions - just how 'only' _is_ 'read-only'?
I'm working on enhancing Perl6::Subs[*] to support more parameter traits than just C. I have some questions about parameters and traits. (These questions all apply to pure Perl 6, which I know I won't be able to translate completely, but I want to know which target I'm missing.) * Given a parameter C, it's obvious I'm not allowed to C, because I didn't say C. But am I allowed to C<@a[0]++>? How about C<@a[0][0]++>? How deep is read-only-ness? * Similarly, how deep is the copy implied by C? * Do traits attach syntactically to the variable name, or to the declaration as a whole? variable: @a is rw of Array Array @a is rw declaration: @a of Array is rw Array @a is rw * As far as I can tell, the choice of spelling an array parameter C or C is entirely cosmetic: both @a and $a are capable of holding an Array reference. Is there actually a difference, e.g. in how they handle an undefined value? [*] Shameless Plug: Perl6::Subs is a source filter that lets you use much of the Perl 6 parameter syntax in your Perl 5 programs; and it enforces many constraints for you. You can even add your own constraints with C subtyping. Amaze your enemies! Confound your friends! Use Perl6::Subs today! -- Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]> Open Source is not an excuse to write fun code then leave the actual work to others.
S28ish [was: [Pugs] A couple of string interpolation edge cases]
On Sat, Mar 26, 2005 at 02:11:29PM +0800, Autrijus Tang wrote: : On Fri, Mar 25, 2005 at 10:03:45PM -0800, Larry Wall wrote: : > Hmm, well, if it got that far. Given strict being on by default, : > this particular example should probably just die on the fact that $" : > isn't declared, since there's no $" in Perl 6. : : Is $" okay as a variable name? Is everything from perlvar.pod legal? :) Considering nobody's written perlvar.pod for Perl 6 yet, yeah, everything in that pod is legal. :-) : my $" = 3; : : Pugs parses that because it only considers $! and $/ as legal : symbolic variable names. $! will be a legal variable name. $/ is going away, as is $", which means they fail under "use strict", but they'd still autocreate globals under laxity as Perl 5 does. (I know Perl 5 exempted all special variables from strict, but I don't see why we have to do that for Perl 6. Merely having $_ in the lexical scope or $*! in the global scope should be sufficient declaration to get around strict. Though perhaps we can exempt people from having to write $*! under strict. In fact, that probably goes for all predeclared $* names, so $IN is legal for $*IN as long as you don't have "my $IN" hiding it. Another way to look at it is that * variables are basically autodeclared "our" implicitly in the outermost lexical scope.) Sigh, I'd better rough it all in here, even if I don't have time to do a good job on it. Maybe somebody can beat this into a real S28 pod. $? and $@ are gone, merged in with $!. (Frees up ? twigil for $?FOO syntax.) $^E is merged too. $! is an object with as much info as you'd like on the current exception (unthrown outside of CATCH, thrown inside). Unthrown exceptions are typically interesting values of undef. $$ is now $*PID. ($$foo is now unambuous.) $0 is gone in favor of $*PROGRAM_NAME or some such. Anything that varied with the selected output filehandle like $| is now a method on that filehande, and the variables don't exist. (The p5-to-p6 translator will probably end up depending on some $Perl5ish::selected_output_filehandle variable to emulate Perl 5's single-arg select().) Likewise $/ and $. should be attached to a particular input filehandle. (In fact, $/ is now the result of the last regular expression match, though we might keep the idea of $. around in some form or other just because it's awfully handy for error messages. But the localizing $. business is yucky. We have to clean that up.) All the special format variables ($%, $=, $-, $:, $~, $^, $^A, $^L) are gone. (Frees up the = twigil for %= POD doc structures and old __DATA__ stream, the : twigil for private attributes, and the ~ twigil for autodeclared parameters.) $`, $', and $+ don't exist any more, but you can dig that info out of $/'s structures. Shortcuts into $/ include $1, $2, and such, and the newfangled $ things. Also, $& is changed to $0 for the whole matched string. $` and $' may be $ and $, but you probably have to explicitly match and to get them remembered, so we don't have a repeat of the Perl 5 sawampersand fiasco. and would automatically exclude themselves from $0. Or you need some special flag to remember them, maybe. %+ and %- are gone. $0, $1, $2, etc. are all objects that know where they .start and .end. (Mind you, those methods return magical positions that are Unicode level independent.) $* and $# have been deprecated half of forever and are gone. $[ is a fossil that I suppose could turn into an evil pragma, if we try to translate it at all. (Frees up * twigil for $*FOO syntax.) $(, $), $<, and $> should all change to various $*FOO names. $] is either something in $* or a trait of the Perl namespace. Likewise $^V, if they aren't in fact merged. ${...} is reserved for hard refs only now. ($::(...) must be used for symbolics refs.) ${^foo} should just change to $*foo or $*_foo or some such. $; is gone because the multidim hash hack is gone. $" is gone, replaced by @foo.join(":") or some such. Likewise for $, in print statements. We never did find a use for $}, thank goodness. And we still are keeping $_ around, though it's lexically scoped. Let's see, what other damage can we do to perlvar. $a and $b are no longer special. No bareword filehandles. $*IN, $*OUT, $*ERR. Args come in @*ARGS rather than @ARGV. (Environment still in %ENV, will wonders never cease.) I don't know whether @INC and %INC will make as much sense when we're looking installed modules in a database, though I suppose you still have to let the user add places to look. %SIG is now %*SIG. The __DIE__ and __WARN__ hooks should be brought out as separate &*ON_DIE and &*ON_WARN variables--they really have nothing to do with signals. I suppose we could even do away with %SIG and replace it with &*ON_SIGINT and such, though then we'd lose a bit of signal introspection which would have to be provided some other way. Oh, and we probably ought to split out &?ON_PARSEERROR from $*ON_DIE to