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 $foo things. Also, $ is changed to $0 for the whole
matched string. $` and $' may be $pre and $post, but you probably
have to explicitly match pre and post to get them remembered,
so we don't have a repeat of the Perl 5 sawampersand fiasco. pre
and post 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
Parameter and trait questions - just how 'only' _is_ 'read-only'?
I'm working on enhancing Perl6::Subs[*] to support more parameter traits than just Cis required. 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 CArray @a, it's obvious I'm not allowed to Cpush @a,1, because I didn't say Cis rw. 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 Cis copy? * 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 CArray @a or CArray $a 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 Cwhere BLOCK 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.
Re: String Theory
Would this be a good time to ask for explanation for Cstr being never Unicode, while CStr 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
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: 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 Cis required. 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 CArray @a, it's obvious I'm not allowed to Cpush @a,1, because I didn't say Cis rw. 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 Cis copy? 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 CArray @a or CArray $a 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 Cwhere BLOCK subtyping. Amaze your enemies! Confound your friends! Use Perl6::Subs today! Cool. Luke
[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: [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
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 $fooish, if they stay.
For $^N, how about $/[-1]?
Luke
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: 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: 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 CArray @a or CArray $a 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 CInt @a and CInt $a. 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: String Theory
Chip Salzenberg wrote: Would this be a good time to ask for explanation for Cstr being never Unicode, while CStr is always Unicode, thus leading to an inability to box a non-Unicode string? That's not quite it. Cstr 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: 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 $fooish, 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: 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 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]
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.
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: 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 CArray @a or CArray $a 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 CArray $a 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.
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'?
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 :CArray @a or CArray $a 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 CArray $a 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: 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 Cis required. 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 CArray @a, it's obvious I'm not allowed to : Cpush @a,1, because I didn't say Cis rw. 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 Cis copy? : : 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 : CArray @a or CArray $a 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: 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..^$end]; Of course,
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 Cstr being : never Unicode, while CStr 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: 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: 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: 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: 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 .somemethodStr,Str?
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'?
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: 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'?
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
