Unify cwd() [was: Re: $*CWD instead of chdir() and cwd()]
On Fri, Apr 15, 2005 at 08:31:57PM -0400, Chip Salzenberg wrote: > According to Michael G Schwern: > > And this is exactly what File::chdir does. $CWD is a tied scalar. > > I don't think current directory maps well on a variable. That won't > stop people from using it, of course. :-( > > There are several methods to determine the current directory. Each > one has its corner cases, strengths and weaknesses (thus the > proliferation of Cwd module functions), and it doesn't make any sense > to me to elevate one over the rest through the proposed $CWD. This is orthoginal to $CWD. Perl 6 is going to have to decide on some sort of standard internal getcwd technique, $CWD or not. In the same way that we have open() not fopen, fdopen, freopen... we can choose the safest and most sensible technique for determining the cwd and use that. You have to because when a new user asks "how do I get the current working directory?" you want to say "cwd()" and not "Well, there are a variety of different techniques..." Cwd.pm is a perfect example of this problem. Which one should a user use? Most folks just won't care and the micro-differences between the functions in Cwd.pm aren't worth the trouble. Present a sensible default. Write a module with all the other options for those who need it. > mkdir '/tmp/foo'; > $CWD = '/tmp/foo'; > rename '../foo', '../bar'; > say $CWD; # Well? Which is it? Its exactly the same as... mkdir '/tmp/foo'; chdir '/tmp/foo'; rename '../foo', '../bar'; say cwd();
Re: $*CWD instead of chdir() and cwd()
According to chromatic:
> On Fri, 2005-04-15 at 23:52 +0200, Juerd wrote:
> > Well, after failure it can be cwd() but false without breaking any real
> > code, because normally, you'd never if (cwd) { ... }, simply because
> > there's ALWAYS a cwd.
>
> Not always -- try removing a directory that's the pwd of another
> process.
Oh, the _directory_ is still there. :-)
--
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: $*CWD instead of chdir() and cwd()
According to Michael G Schwern: > And this is exactly what File::chdir does. $CWD is a tied scalar. I don't think current directory maps well on a variable. That won't stop people from using it, of course. :-( There are several methods to determine the current directory. Each one has its corner cases, strengths and weaknesses (thus the proliferation of Cwd module functions), and it doesn't make any sense to me to elevate one over the rest through the proposed $CWD. mkdir '/tmp/foo'; $CWD = '/tmp/foo'; rename '../foo', '../bar'; say $CWD; # Well? Which is it? -- 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: $*CWD instead of chdir() and cwd()
On Fri, Apr 15, 2005 at 03:22:48PM -0700, Michael G Schwern wrote:
: On Fri, Apr 15, 2005 at 11:52:38PM +0200, Juerd wrote:
: > > becomes an unverifiable operation. You have to use chdir() if you want to
: > > error check and $CWD is reduced to a "scripting" feature.
: >
: > Well, after failure it can be cwd() but false without breaking any real
: > code, because normally, you'd never if (cwd) { ... }, simply because
: > there's ALWAYS a cwd. If this is done, the thing returned by the STORE
: > can still be an lvalue and thus be properly reffed.
:
: Good idea!
But if cwd() or chdir() doesn't fail(), you probably won't get any
information on *why* the chdir failed in either the return value or $!.
That could be construed as antisocial.
In general I think "but" should be reserved for situations where the
original interface designer showed sufficient lack of imagination to
warrant such workarounds. That is how I treated all the RFCs that
made use of "but" for built-in functionality, and I haven't seen any
good reasons to alter my views on that. About the closest we get
to it is that "interesting values of undef" can be thought of as new
Exception(...) but undefined, or some such. But even that is usually
hidden behind the fail() predicate, and the undef role is probably
composed into exceptions in the first place. Or maybe it's the
other way around.
Larry
Re: $*CWD instead of chdir() and cwd()
On Fri, Apr 15, 2005 at 11:52:38PM +0200, Juerd wrote:
> > becomes an unverifiable operation. You have to use chdir() if you want to
> > error check and $CWD is reduced to a "scripting" feature.
>
> Well, after failure it can be cwd() but false without breaking any real
> code, because normally, you'd never if (cwd) { ... }, simply because
> there's ALWAYS a cwd. If this is done, the thing returned by the STORE
> can still be an lvalue and thus be properly reffed.
Good idea!
Re: Comparing rationals/floats
At 16:18 -0700 4/15/05, gcomnz wrote: >More questions stemming from cookbook work... Decimal Comparisons: > >The most common recipe around for comparisons is to use sprintf to cut >the decimals to size and then compare strings. Seems ugly. > >The non-stringification way to do it is usually along the lines of: > >if (abs($value1 - $value2) < abs($value1 * epsilon)) > >(From Mastering Algorithms with Perl errata) > >I'm wondering though, if C<$value1 == $value2> is always wrong (or >almost always wrong) then should it be smarter and: >SNIP >Marcus Adair I have longed for an OO class that might be called "measurement". An object would include a float, a unit of measure, and an estimate of accuracy. Mathematical operations would be overloaded so that the result of a calculation would appropriately handle propagation of the argument's accuracies into the result. It might even do unit conversions but that's another subject. Coercion of a float into a measurement would be automatic with infinite precision assumed. Given the new class it is easy to adjust comparison operators to calculate "within experimental error". -- --> Life begins at ovulation. Ladies should endeavor to get every young life fertilized. <--
Comparing rationals/floats
More questions stemming from cookbook work... Decimal Comparisons: The most common recipe around for comparisons is to use sprintf to cut the decimals to size and then compare strings. Seems ugly. The non-stringification way to do it is usually along the lines of: if (abs($value1 - $value2) < abs($value1 * epsilon)) (From Mastering Algorithms with Perl errata) I'm wondering though, if C<$value1 == $value2> is always wrong (or almost always wrong) then should it be smarter and: a. throw a warning b. DWIM using overloaded operators (as in reduce precision then compare) c. throw a warning but have other comparison operators just for this case to make sure you know what you're doing I'd vote for b., but I don't know enough about the problem domain to know if that is safe, and realistically I just want to write the cookbook entry rather than start a math-geniuses flame war ;-) Which leads to another question: Are there $value.precision() and $value.accuracy() methods available for decimals? I'd really rather not do the string comparison if it can be avoided, maybe it's just the purist in me saying "leave the numbers be" :-) Apologies in advance if this is somewhere I missed. I did a lot of searching. Marcus Adair
Re: nbsp in \s, and <>
I thought we had just established that nbsp is not in Unicode¹s definition of whitespace. So why should \s match it? On 2005-04-15 18:56, "Larry Wall" <[EMAIL PROTECTED]> wrote: > On Sat, Apr 16, 2005 at 12:46:47AM +0200, Juerd wrote: > : Larry Wall skribis 2005-04-15 15:38 (-0700): > : > : Do \s and match non-breaking whitespace, U+00A0? > : > Yes. > : > : That makes \s+ and \s*, and thus very useless for anything but > : trimming whitespace. For splitting (including word wrapping), it'd do > : exactly the wrong thing. > > Maybe we just need a for breaking white space, or some such. > is primarily used in pattern matching with :w, where a > non-breaking space in the input would presumably be matched by a > non-breaking space in the pattern, or maybe an explicit . > As long as patterns (with or without :w) treat non-breaking spaces > as ordinary matching characters, it should work out, methinks. > Though it's probably a hair more readable to use an explicit ... > > Larry >
Re: nbsp in \s, and <>
On Sat, Apr 16, 2005 at 12:46:47AM +0200, Juerd wrote: : Larry Wall skribis 2005-04-15 15:38 (-0700): : > : Do \s and match non-breaking whitespace, U+00A0? : > Yes. : : That makes \s+ and \s*, and thus very useless for anything but : trimming whitespace. For splitting (including word wrapping), it'd do : exactly the wrong thing. Maybe we just need a for breaking white space, or some such. is primarily used in pattern matching with :w, where a non-breaking space in the input would presumably be matched by a non-breaking space in the pattern, or maybe an explicit . As long as patterns (with or without :w) treat non-breaking spaces as ordinary matching characters, it should work out, methinks. Though it's probably a hair more readable to use an explicit ... Larry
Re: Heredocs: How equal are bunches of spaces to tabs?
On Sat, Apr 16, 2005 at 12:11:24AM +0200, Juerd wrote: : Pasted from pugs/examples/cookbook/01-00introduction.p6: : : # XXX - question: How equal are bunches of spaces to tabs? : # -- I'd say that's a question for perl6lang This seems to be singularly short on context, but if it has to do with trimming leading whitespace from heredocs, A2 already discusses this. Larry
Re: nbsp in \s, and <>
Larry Wall skribis 2005-04-15 15:38 (-0700): > : Do \s and match non-breaking whitespace, U+00A0? > Yes. That makes \s+ and \s*, and thus very useless for anything but trimming whitespace. For splitting (including word wrapping), it'd do exactly the wrong thing. > : \s is said (in S05) to match any unicode whitespace, but letting it > : match NBSP and then using \s for splitting things is wrong, I think. > Perhaps the default word split should not be based on \s then. It'd have to. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: nbsp in \s, and <>
On Fri, Apr 15, 2005 at 11:44:03PM +0200, Juerd wrote: : Is there a -like thingy that is always \s+? Not currently, since \s+ is there. used to be that, but currently is defined as the magical whitespace matcher used by :words. : Do \s and match non-breaking whitespace, U+00A0? Yes. : How about: : : U+0008 backspace : U+00A0 no break space (Repeated for overview) : U+1361 ethiopic wordspace : U+2000 en quad : U+2001 em quad : U+2002 en space : U+2003 em space : U+2004 three per em space : U+2005 four per em space : U+2006 six per em space : U+2007 figure space : U+2008 punctuation space : U+2009 thin space : U+200A hair space : U+200B zero width space : U+202F narrow no break space : U+205F medium mathematic space : U+2060 word joiner (What is that, anyway?) : U+3000 ideographic space : U+FEFF zero width non-breaking space Yes, any Unicode whitespace, but you seem to have a different list than I do. Outside of the standard ASCIIish control-character whitespace, I count only the \pZ characters, not the \pC characters, so I don't have to tell you what a word-joiner is, since it's a \p[Cf] character. :-) I will also gleefully ignore the existence of BOMs. So I make it: 0020;SPACE;Zs;0;WS;N; 00A0;NO-BREAK SPACE;Zs;0;CS; 0020N;NON-BREAKING SPACE 1680;OGHAM SPACE MARK;Zs;0;WS;N; 180E;MONGOLIAN VOWEL SEPARATOR;Zs;0;WS;N; 2000;EN QUAD;Zs;0;WS;2002N; 2001;EM QUAD;Zs;0;WS;2003N; 2002;EN SPACE;Zs;0;WS; 0020N; 2003;EM SPACE;Zs;0;WS; 0020N; 2004;THREE-PER-EM SPACE;Zs;0;WS; 0020N; 2005;FOUR-PER-EM SPACE;Zs;0;WS; 0020N; 2006;SIX-PER-EM SPACE;Zs;0;WS; 0020N; 2007;FIGURE SPACE;Zs;0;WS; 0020N; 2008;PUNCTUATION SPACE;Zs;0;WS; 0020N; 2009;THIN SPACE;Zs;0;WS; 0020N; 200A;HAIR SPACE;Zs;0;WS; 0020N; 200B;ZERO WIDTH SPACE;Zs;0;BN;N; 2028;LINE SEPARATOR;Zl;0;WS;N; 2029;PARAGRAPH SEPARATOR;Zp;0;B;N; 202F;NARROW NO-BREAK SPACE;Zs;0;WS; 0020N; 205F;MEDIUM MATHEMATICAL SPACE;Zs;0;WS; 0020N; 3000;IDEOGRAPHIC SPACE;Zs;0;WS; 0020N; : \s is said (in S05) to match any unicode whitespace, but letting it : match NBSP and then using \s for splitting things is wrong, I think. Perhaps the default word split should not be based on \s then. It's just one more difference, in addition to trimming leading and trailing whitespace like awk. : Are the contents of <> split using ? (Is <<$foo>>, where $foo is : "foo\xA0bar", one or two elements?) That is using the default word splitter (or it *is* the default word splitter), so if the default word split is based on <+[\s]-[\xA0]> it would be one element. Of course, the ZERO WIDTH SPACE is a nasty critter for anyone using whitespace to separate tokens. That and maybe thin spaces probably merit warnings in Perl code where they might cause visual ambiguity. Larry
Re: nbsp in \s, and <>
Aaron Sherman skribis 2005-04-15 18:20 (-0400): > > Is there a -like thingy that is always \s+? > Not sure what that means exactly. is \s* or \s+, depending on its surroundings. > Thankfully, NBSP (U+00A0) is not Unicode whitespace. Thanks for sharing this information! Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: $*CWD instead of chdir() and cwd()
chromatic skribis 2005-04-15 15:18 (-0700):
> > Well, after failure it can be cwd() but false without breaking any real
> > code, because normally, you'd never if (cwd) { ... }, simply because
> > there's ALWAYS a cwd.
> Not always -- try removing a directory that's the pwd of another
> process.
Results in EPERM indeed :(
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: nbsp in \s, and <>
On Fri, 2005-04-15 at 17:44, Juerd wrote: > Is there a -like thingy that is always \s+? Not sure what that means exactly. > Do \s and match non-breaking whitespace, U+00A0? As I understood, Perl 6 was going to use the Unicode standard(s) to determine the whitespacishness of each codepoint. Going to Google, I find: http://www.fileformat.info/info/unicode/category/Zs/list.htm which lists all of the "separator, space" characters. > How about: > > U+0008 backspace Character.isWhitespace() No > U+00A0 no break space (Repeated for overview) Character.isWhitespace() No > U+1361 ethiopic wordspace Character.isWhitespace() No > U+2000 en quad Character.isWhitespace() Yes > U+2001 em quad Character.isWhitespace() Yes > U+2002 en space Character.isWhitespace() Yes > U+2003 em space Character.isWhitespace() Yes > U+2004 three per em space Character.isWhitespace() Yes > U+2005 four per em space Character.isWhitespace() Yes > U+2006 six per em space Character.isWhitespace() Yes > U+2007 figure space Character.isWhitespace() No > U+2008 punctuation space Character.isWhitespace() Yes > U+2009 thin space Character.isWhitespace() Yes > U+200A hair space Character.isWhitespace() Yes > U+200B zero width space Character.isWhitespace() Yes > U+202F narrow no break space Character.isWhitespace() No > U+205F medium mathematic space Character.isWhitespace() Yes > U+2060 word joiner (What is that, anyway?) Character.isWhitespace() No Comments WJ a zero width non-breaking space (only) intended for disambiguation of functions for byte order mark > U+3000 ideographic space Character.isWhitespace() Yes > U+FEFF zero width non-breaking space Character.isWhitespace() No > \s is said (in S05) to match any unicode whitespace, but letting it > match NBSP and then using \s for splitting things is wrong, I think. Thankfully, NBSP (U+00A0) is not Unicode whitespace. -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: $*CWD instead of chdir() and cwd()
On Fri, 2005-04-15 at 23:52 +0200, Juerd wrote:
> Well, after failure it can be cwd() but false without breaking any real
> code, because normally, you'd never if (cwd) { ... }, simply because
> there's ALWAYS a cwd.
Not always -- try removing a directory that's the pwd of another
process.
-- c
Heredocs: How equal are bunches of spaces to tabs?
Pasted from pugs/examples/cookbook/01-00introduction.p6: # XXX - question: How equal are bunches of spaces to tabs? # -- I'd say that's a question for perl6lang Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: $*CWD instead of chdir() and cwd()
On Fri, Apr 15, 2005 at 01:12:46PM -0700, Michael G Schwern wrote:
: Thus spake Larry Wall:
: > Offhand, I guess my main semantic problem with it is that if a chdir
: > fails, you aren't in an undefined location, which the new value of $CWD
: > would seem to indicate. You're just where you were. Then the user
: > either has to remember that, or there still has to be some other
: > means of finding out the real location.
:
: To be clear: Only the store operation will return undef on failure.
That doesn't square with the notion that an assignment returns the
actual lvalue:
($new = $old) =~ s/foo/bar/;
: Additional fetches on $CWD will continue to return the cwd.
:
: $CWD = '/path/which/exists';
: $CWD = '/i/do/not/exist' err warn $!;
: print $CWD;
:
: This prints /path/which/exists/.
Except that the err should be looking at $CWD, not some other return value
of the assignment.
: > The other problem with it is the fact that people will assign relative
: > paths to it and expect to get the relative path back out instead
: > of the absolute path.
:
: I honestly never had this problem until I sat down and thought about it. :)
: THEN I got all confused and started to do things like $CWD .= '/subdir';
: instead of simply $CWD = 'subdir';. But the rule is simple and natural.
: It takes a relative or absolute directory and ALWAYS returns an absolute
: path. Lax in what inputs it accepts, strict in what it emits. This is no
: more to remember than what chdir() and cwd() would do.
:
: The result from $CWD would simply be a Dir object similar to Ken Williams'
: Path::Class or Ruby's Dir object. One of the methods would be .relative.
:
: I didn't bring up @CWD because I thought it would be too much in one sitting.
: Basically it allows you to do this:
:
: pop @CWD; # chdir ('..');
: push @CWD, 'dir'; # chdir ('dir');
: print $CWD[0]; # (File::Spec->splitdir(abs_path()))[0];
: # ie. What top level directory am I in?
:
: and all sorts of other operations that would normally involve a lot of
: splitdir'ing.
:
: And then there's %CWD which I'm toying with being a per-volume chdir like
: you can do on Windows but that may be too much of a questionable thing.
You could multiplex both the array and hash roles into the object
returned by $CWD, much like the $/ pattern match result object can
be subscripted as either $/[1] or $/. $CWD would itself
behave like a string in string context, but $CWD[] would get you to
the array value, and $CWD{} the hash value for systems that have
more than one current directory.
: > Your assumption there is a bit inaccurate--in P6 you are allowed to
: > temporize (localize) the effects of functions and methods that are
: > prepared to deal with it.
:
: Yeah, we were talking about it on #perl6 a bit. That seems to me the more
: bizarre idea than assigning to something which can fail. Localizing an
: assignment is easy, there's just one thing to revert. But function calls can
: do lots of things. Just how much does it reverse? I guess if its used
: sensibly on sharp functions, such as chdir, and the behavior is
: user-definable it can work but I don't know if the behavior will ever
: be obvious for anything beyond the trivial.
The function reverses whatever its TEMP property's closure knows how
to reverse. It's up to the function to know what its side effects are
and arrange to undo them.
: FWIW my prompting to write File::chdir was a desire was for "local chdir".
: So if "temp chdir" can be made to work that would solve most of the problem.
:
: If nothing else perhaps chdir() should be eliminated and cwd() simply takes
: an argument to make it a getter/setter.
If you're going to throw away the verb then the noun might as well be
a variable. But I like verbs for their readability, even if the verb
is "push". Note that "push" could be made to work with "temp" as well:
temp push $CWD, "subdir" err fail "..."
This would automatically pop $CWD at the end of the dynamic scope.
: > However, I agree that it's nice to have an
: > easily interpolatable value. So I think I'd rather see $CWD always
: > return the current absolute path even after failure
:
: The problem there is it leaves $CWD without an error mechanism and thus
: becomes an unverifiable operation. You have to use chdir() if you want to
: error check and $CWD is reduced to a "scripting" feature.
That was my point. And if you look back at what you wrote, you just
called $CWD an "operation". It's not--it's a noun. I like nouns,
but I also like verbs, and unlike in Perl 5 we don't have to rely on
the magical side effects of certain mystical nouns to do localization
any more.
But I don't understand what you mean by a "scripting" feature, or
how getting reduced to one is antithetical to a blissful existence.
: It could throw an exception but then you have to wrap everything in a try
: block. U
Re: $*CWD instead of chdir() and cwd()
Michael G Schwern skribis 2005-04-15 13:12 (-0700):
> To be clear: Only the store operation will return undef on failure.
> Additional fetches on $CWD will continue to return the cwd.
Still breaks
$ref = \($CWD = $foo);
I'm not sure this breakage matters, but if it breaks one thing, it's
likely to break more than just that one thing, and I wonder how much
attention this has been given.
Hm, but $CWD++ is nice! Especially if after photos9 it goes to photos10,
and not photot0. How does string ++ work in Perl 6, anyway?
> The problem there is it leaves $CWD without an error mechanism and thus
> becomes an unverifiable operation. You have to use chdir() if you want to
> error check and $CWD is reduced to a "scripting" feature.
Well, after failure it can be cwd() but false without breaking any real
code, because normally, you'd never if (cwd) { ... }, simply because
there's ALWAYS a cwd. If this is done, the thing returned by the STORE
can still be an lvalue and thus be properly reffed.
This would mean you'd use or instead of err, but I don't understand the
point of err meaning "error" together with the introduction of
true-but-false values anyway. Low-prec // should imo just be spelled
dor. But it's too late for that, of course.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
nbsp in \s, and <>
Is there a -like thingy that is always \s+? Do \s and match non-breaking whitespace, U+00A0? How about: U+0008 backspace U+00A0 no break space (Repeated for overview) U+1361 ethiopic wordspace U+2000 en quad U+2001 em quad U+2002 en space U+2003 em space U+2004 three per em space U+2005 four per em space U+2006 six per em space U+2007 figure space U+2008 punctuation space U+2009 thin space U+200A hair space U+200B zero width space U+202F narrow no break space U+205F medium mathematic space U+2060 word joiner (What is that, anyway?) U+3000 ideographic space U+FEFF zero width non-breaking space \s is said (in S05) to match any unicode whitespace, but letting it match NBSP and then using \s for splitting things is wrong, I think. Are the contents of <> split using ? (Is <<$foo>>, where $foo is "foo\xA0bar", one or two elements?) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Statement modifier scope
Paul Seamons skribis 2005-04-15 13:42 (-0600): > Each of the declarations my, our and local currently set the value to > undefined (unless set = to something). That's not true. use strict; $::foo = 5; our $foo; print $foo; # 5 Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: $*CWD instead of chdir() and cwd()
Thus spake Larry Wall:
> Offhand, I guess my main semantic problem with it is that if a chdir
> fails, you aren't in an undefined location, which the new value of $CWD
> would seem to indicate. You're just where you were. Then the user
> either has to remember that, or there still has to be some other
> means of finding out the real location.
To be clear: Only the store operation will return undef on failure.
Additional fetches on $CWD will continue to return the cwd.
$CWD = '/path/which/exists';
$CWD = '/i/do/not/exist' err warn $!;
print $CWD;
This prints /path/which/exists/.
> The other problem with it is the fact that people will assign relative
> paths to it and expect to get the relative path back out instead
> of the absolute path.
I honestly never had this problem until I sat down and thought about it. :)
THEN I got all confused and started to do things like $CWD .= '/subdir';
instead of simply $CWD = 'subdir';. But the rule is simple and natural.
It takes a relative or absolute directory and ALWAYS returns an absolute
path. Lax in what inputs it accepts, strict in what it emits. This is no
more to remember than what chdir() and cwd() would do.
The result from $CWD would simply be a Dir object similar to Ken Williams'
Path::Class or Ruby's Dir object. One of the methods would be .relative.
I didn't bring up @CWD because I thought it would be too much in one sitting.
Basically it allows you to do this:
pop @CWD; # chdir ('..');
push @CWD, 'dir'; # chdir ('dir');
print $CWD[0]; # (File::Spec->splitdir(abs_path()))[0];
# ie. What top level directory am I in?
and all sorts of other operations that would normally involve a lot of
splitdir'ing.
And then there's %CWD which I'm toying with being a per-volume chdir like
you can do on Windows but that may be too much of a questionable thing.
> Your assumption there is a bit inaccurate--in P6 you are allowed to
> temporize (localize) the effects of functions and methods that are
> prepared to deal with it.
Yeah, we were talking about it on #perl6 a bit. That seems to me the more
bizarre idea than assigning to something which can fail. Localizing an
assignment is easy, there's just one thing to revert. But function calls can
do lots of things. Just how much does it reverse? I guess if its used
sensibly on sharp functions, such as chdir, and the behavior is
user-definable it can work but I don't know if the behavior will ever
be obvious for anything beyond the trivial.
FWIW my prompting to write File::chdir was a desire was for "local chdir".
So if "temp chdir" can be made to work that would solve most of the problem.
If nothing else perhaps chdir() should be eliminated and cwd() simply takes
an argument to make it a getter/setter.
> However, I agree that it's nice to have an
> easily interpolatable value. So I think I'd rather see $CWD always
> return the current absolute path even after failure
The problem there is it leaves $CWD without an error mechanism and thus
becomes an unverifiable operation. You have to use chdir() if you want to
error check and $CWD is reduced to a "scripting" feature.
It could throw an exception but then you have to wrap everything in a try
block. Unless Perl 6 is going this route for I/O errors in general I'd
rather not.
I'll give the error mechanism some more thought.
Anyhow, I encourage folks to play with File::chdir and see what they think
of the idea. I'm fixing up the Windows nits in the tests now.
Re: Statement modifier scope
> I'm imagining it will be different, as I expect temp to not hide the old > thing. I'm not sure it will. That is another good question. I just searched through the S and A's and couldn't find if temp will blank it out. I am thinking it will act like local. Each of the declarations my, our and local currently set the value to undefined (unless set = to something). I imagine that temp and let will behave the same. In which case "local %h;" and "let %h" would allocate a new, empty variable in a addition to the original variable (which is hidden but still retains its contents). Paul
Re: Statement modifier scope
I would like to get rid of all those implicit scopes. The only exception would be that any topicalizing modifier allocates a private lexical $_ scoped to just that statement. But dynamic scoping may happen only at explicit block boundaries. I can see the argument for the other side, where any "deferred" code is treated as a kind of closure regardless of whether there are explicit curlies around it. That would solve certain problems like defining the scopes of the lexicals in $a = $x ?? my $y :: my $z; or the infamous my $x = 1 if $y; to extend only to the subexpressions in which they find themselves. But it's not what naive users expect, and it's hard to explain, so I think we should stick with explicit curlies for most of our scoping needs, even if it means letting certain variables hang around undefined because their initialization was never executed. Larry
Re: Statement modifier scope
Paul Seamons skribis 2005-04-15 12:41 (-0600):
> In Perl5
> perl -MData::Dumper -e '%h=qw(a 1 b 2); {local %h; $h{a}="one"; print Dumper
> \%h} print Dumper \%h;
> $VAR1 = {
> 'a' => 'one'
> };
> $VAR1 = {
> 'a' => '1',
> 'b' => '2'
> };
> I'm imaging the behavior would be the same with Perl6. Notice that 'b' is
I'm imagining it will be different, as I expect temp to not hide the old
thing. I'm not sure it will.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: should we change [^a-z] to <-[a..z]> instead of <-[a-z]>?
On Fri, Apr 15, 2005 at 11:28:31AM -0500, Rod Adams wrote: : David Wheeler wrote: : : >But the first person to write <[a...]> gets what's comin' to 'em. : : Is that nothing (since '.' lt 'a'), or everything after 'a'? Might as well make it everything after 'a' for consistency. One could also view the last dot as a special version of the ordinary "any" dot, and read it "a to whatever". Larry
Re: Statement modifier scope
On Friday 15 April 2005 12:28 pm, Juerd wrote:
> temp %h{ %other.keys } = %other.values;
Oops missed that - I like that for solving this particular problem. It does
even work in Perl5:
perl -MData::Dumper -e '%h=qw(a 1 b 2); {local @h{qw(a b)}=("one","two");
print Dumper \%h} print Dumper \%h'
$VAR1 = {
'a' => 'one',
'b' => 'two'
};
$VAR1 = {
'a' => '1',
'b' => '2'
};
I had never thought to do a hash slice in a local. That is great!!!
Thank you very much! Wish I'd know about that three years ago.
But, it still doesn't answer the original question about scoping in the
looping statement modifiers.
Paul
Re: Truely temporary variables
On Fri, 2005-04-15 at 13:10, Luke Palmer wrote:
> Aaron Sherman writes:
> > Among the various ways of declaring variables, will Perl 6 have a way to
> > say, "this variable is highly temporary, and may be re-declared within
> > the same scope, or in a nested scope without concern"? I often find
> > myself doing:
> >
> > my $sql = q{...};
> > ...do some DB stuff...
> > my $sql = q{...};
> > ...do more DB stuff...
>
> There's a pretty common idiom for this:
>
> {
> my $sql = q{...};
> # ... do some DB stuff ...
> }
> {
> my $sql = q{...};
> # ... do more DB stuff ...
> }
>
> You see it in test suites all over the CPANdom.
You see it all over my code too... it is always possible to simulate
many kinds of trickery that way. For example, if you want to write a
loop with a counter that is visible one statement after the loop
completes, you can say:
{
my int $i;
loop $i=0;...;$i++ {
...
}
do_stuff($i);
}
But isn't:
loop my int $i=0;...;$i++ {
...;
LAST{do_stuff($i)}
}
much cleaner? I think so, if for no other reason than it explicitly says
what it means. That's one of the reasons that LAST is so handy.
So too would my mythical declarator would prevent a few steps that are
otherwise quite easy, but cumbersome in the large.
Whatever, though. It was a simple suggestion, and seems to have sparked
FAR more controversy than the small win warrants.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: Statement modifier scope
>
> temp %h;
> %h{ %other.keys } = %other.values;
>
> or even
>
> temp %h{ %other.keys } = %other.values;
>
> should work well already?
Almost - but not quite.
In Perl5
perl -MData::Dumper -e '%h=qw(a 1 b 2); {local %h; $h{a}="one"; print Dumper
\%h} print Dumper \%h;
$VAR1 = {
'a' => 'one'
};
$VAR1 = {
'a' => '1',
'b' => '2'
};
I'm imaging the behavior would be the same with Perl6. Notice that 'b' is
gone in the first print. I only want to temporarily modify "some" values
(the ones from the %other hash). I don't want the contents of the %h to be
identical to %other - I already have %other.
So in Perl5 this does work:
perl -MData::Dumper -e '%h=qw(a 1 b 2); {local %h=%h; $h{a}="one"; print
Dumper \%h} print Dumper \%h;
$VAR1 = {
'a' => 'one'
'b' => '2',
};
$VAR1 = {
'a' => '1',
'b' => '2'
};
But this won't work in Perl6 (temp $var = $var doesn't work in Perl6) and
again it may be fine for small hashes with only a little data - but for a
huge hash (1000+ keys) it is very inefficient.
This is good discussion - but it isn't the real focus of the original message
in the thread - the question is about the local (temp) scoping of looping
statement modifiers in Perl6.
Though, I do appreciate your trying to get my example working as is.
Paul
Re: Statement modifier scope
Paul Seamons skribis 2005-04-15 12:16 (-0600):
> For the given example, your code fits perfectly. A more common case I have
> had to deal with is more like this:
> my %h =
> my %other = ;
> {
> temp %h{$_} = %other{$_} for %other.keys;
Either
temp %h;
%h{$_} = %other{$_} for %other.keys;
or
temp %h;
%h{ %other.keys } = %other.values;
or even
temp %h{ %other.keys } = %other.values;
should work well already?
> %h.say;
> }
I think it's hard to find an example that can't easily be rewritten as
something that already works. Gather/take solves most.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Truely temporary variables
On Fri, 2005-04-15 at 11:21 -0500, Patrick R. Michaud wrote: > On Fri, Apr 15, 2005 at 09:17:13AM -0700, Larry Wall wrote: > > Maybe we could define an "ok" operator that suppresses only the > > *first* warning produced by its argument(s). Then if you get multiple > > warnings, you at least get some indication that you've overgeneralized, > > even if the "wrong" warning comes out. Or maybe it only suppresses > > the first warning till you get a second warning, and then it prints both. > And after the third warning, it sends you to your room with no supper. Talk about a strict permission system. If that's the case, I want a "I'm the human here, darnit!" option to bypass it. -- c
Re: Truely temporary variables
Brent 'Dax' Royal-Gordon skribis 2005-04-15 11:15 (-0700):
> Anything wrong with:
Yes, moving things around breaks it, as does removing the first. There
is no real dependency on the first $sql and it'd be great if declaration
wouldn't add one.
temp $sql = q{...};
my $sql = q{...};
temp $sql = q{...};
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Statement modifier scope
On Friday 15 April 2005 11:57 am, Juerd wrote:
> Paul Seamons skribis 2005-04-15 11:50 (-0600):
> > my %h = ;
> > {
> > temp %h{$_} ++ for %h.keys;
>
> Just make that two lines. Is that so bad?
>
> temp %h;
> %h.values »++;
>
For the given example, your code fits perfectly. A more common case I have
had to deal with is more like this:
my %h =
my %other = ;
{
temp %h{$_} = %other{$_} for %other.keys;
%h.say;
}
Ideally that example would print
aone
btwo
c3
It isn't possible any more to do something like
{
temp %h = (%h, %other);
}
because that second %h is now hidden from scope (I forget which Apocalypse or
mail thread I saw it in). Plus for huge hashes it just isn't very efficient.
I'd like to temporarily put the values of one hash into another (without
wiping out all of the modfied hashes values like "temp %h" would do), run
some code, leave scope and have the modified hash go back to normal. In
perl5 I've had to implement that programatically by saving existing values
into yet another hash - running the code - putting them back. It works but
there is all sorts of issues with defined vs exists.
So yes - your code fits the limited example I gave. But I'd still like the
other item to work.
Paul
Re: Truely temporary variables
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> What I'd really like to say is:
>
> throwawaytmpvar $sql = q{...};
> throwawaytmpvar $sql = q{...};
Anything wrong with:
my $sql = q{...};
temp $sql = q{...};
temp $sql = q{...};
(Assuming C is made to work on lexicals, of course.)
--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
"I used to have a life, but I liked mail-reading so much better."
Re: Statement modifier scope
Paul Seamons skribis 2005-04-15 11:50 (-0600):
> my %h = ;
> {
> temp %h{$_} ++ for %h.keys;
Just make that two lines. Is that so bad?
temp %h;
%h.values »++;
> %h.say; # values are incremented still
> }
> %h.say; # values are back to original values
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Statement modifier scope
The following chunks behave the same in Perl 5.6 as in Perl 5.8. Notice the
output of "branching" statement modifiers vs. "looping" statement modifiers.
perl -e '$f=1; {local $f=2; print "$f"} print " - $f\n"'
# prints 2 - 1
perl -e '$f=1; {local $f=2 if 1; print "$f"} print " - $f\n"
# prints 2 - 1
perl -e '$f=1; {local $f=2 unless 0; print "$f"} print " - $f\n"''
# prints 2 - 1
perl -e '$f=1; {local $f=2 for 1; print "$f"} print " - $f\n"'
# prints 1 - 1
perl -e '$f=1; {local $f=2 until 1; print "$f"} print " - $f\n"'
# prints 1 - 1
perl -e '$f=1; {local $f=2 while !$n++; print "$f"} print " - $f\n"'
# prints 1 - 1
It appears that there is an implicit block around statements with looping
statement modifiers. perlsyn does state that the control variables of the
"for" statement modifier are locally scoped, but doesn't really mention that
the entire statement is as well. I'm not sure if this was in the original
design spec or if it flowed out of the implementation details, but either way
it seems to represent an inconsistency in the treatment of locality with
regards to braces (ok I guess there are several in Perl5).
So the question is, what will it be like for Perl6. It would seem that all of
the following should hold true because of scoping being tied to the blocks.
pugs -e 'our $f=1; {temp $f=2; print $f}; say " - $f"'
# should print 2 - 1 (currently prints 2 - 2 - but that is a compiler
issue)
pugs -e 'our $f=1; {temp $f=2 if 1; print $f}; say " - $f"'
# should print 2 - 1 (currently dies with parse error)
pugs -e 'our $f=1; {temp $f=2 for 1; print $f}; say " - $f"'
# hopefully prints 2 - 1 (currently dies with parse error)
As a side note - pugs does work with:
pugs -e 'our $f=1; {$f=2 for 1; print $f}; say " - $f"'
# prints 2 - 2 (as it should. It seems that statement modifiers don't
currently work with declarations - but that is a compiler issue - not a
language issue.)
I have wanted to do this in Perl5 but couldn't but would love to be able to do
in Perl6:
my %h = ;
{
temp %h{$_} ++ for %h.keys;
%h.say; # values are incremented still
}
%h.say; # values are back to original values
Paul
Re: Truely temporary variables
Aaron Sherman writes:
> Among the various ways of declaring variables, will Perl 6 have a way to
> say, "this variable is highly temporary, and may be re-declared within
> the same scope, or in a nested scope without concern"? I often find
> myself doing:
>
> my $sql = q{...};
> ...do some DB stuff...
> my $sql = q{...};
> ...do more DB stuff...
There's a pretty common idiom for this:
{
my $sql = q{...};
# ... do some DB stuff ...
}
{
my $sql = q{...};
# ... do more DB stuff ...
}
You see it in test suites all over the CPANdom.
Luke
Re: Truely temporary variables
Rod Adams skribis 2005-04-15 11:53 (-0500): > Wouldn't some form of trait make more sense: >my $sql = '...' is ok; Depends. A unary ok operator would let you pinpoint very easily, *without* using parens: ok $fh.print($foo); # no warnings about print (closed fh?) # but warning about undef $foo remains $fh.print(ok $foo); # warn about printing thingies, but not about # undef $foo say $foo, $bar, ok $baz, $quux; # complain about everything, except # what has to do with $baz my $foo; ok my $foo = "foo $bar baz"; # warn about $bar, but not the masking my $foo = ok "foo $bar baz"; # other way around Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Truely temporary variables
Larry Wall wrote:
On Fri, Apr 15, 2005 at 06:04:32PM +0200, Juerd wrote:
: No, Ucfirst it can't be, I think. And ALLCAPS is ugly. @ is taken (and
: ugly). Suggestions?
Maybe we could define an "ok" operator that suppresses only the
*first* warning produced by its argument(s). Then if you get multiple
warnings, you at least get some indication that you've overgeneralized,
even if the "wrong" warning comes out. Or maybe it only suppresses
the first warning till you get a second warning, and then it prints both.
Wouldn't some form of trait make more sense:
my $sql = '...' is ok;
Only trick would be getting "is ok" to bind to the thing in the
preceding expression that produces the warning the programmer was
expecting. Certainly
{my $sql = '...'} is ok;
get the point across that warnings are somewhat ignorable for the block,
but that starts getting to look a lot like
{my $sql = '...'} CATCH {default};
Except that one is run-time, the other compile-time.
So one could interpret this thread as a cry for a compile-time exception
handler. I see some interesting uses for this in conjunction with
C, but I doubt I'm seeing the whole story.
-- Rod Adams
Re: should we change [^a-z] to <-[a..z]> instead of <-[a-z]>?
David Wheeler wrote: But the first person to write <[a...]> gets what's comin' to 'em. Is that nothing (since '.' lt 'a'), or everything after 'a'? -- Rod Adams
Re: Truely temporary variables
On Fri, Apr 15, 2005 at 09:17:13AM -0700, Larry Wall wrote: > On Fri, Apr 15, 2005 at 06:04:32PM +0200, Juerd wrote: > : No, Ucfirst it can't be, I think. And ALLCAPS is ugly. @ is taken (and > : ugly). Suggestions? > > Maybe we could define an "ok" operator that suppresses only the > *first* warning produced by its argument(s). Then if you get multiple > warnings, you at least get some indication that you've overgeneralized, > even if the "wrong" warning comes out. Or maybe it only suppresses > the first warning till you get a second warning, and then it prints both. And after the third warning, it sends you to your room with no supper. Pm
Re: Truely temporary variables
On Fri, Apr 15, 2005 at 06:04:32PM +0200, Juerd wrote: : No, Ucfirst it can't be, I think. And ALLCAPS is ugly. @ is taken (and : ugly). Suggestions? Maybe we could define an "ok" operator that suppresses only the *first* warning produced by its argument(s). Then if you get multiple warnings, you at least get some indication that you've overgeneralized, even if the "wrong" warning comes out. Or maybe it only suppresses the first warning till you get a second warning, and then it prints both. Larry
Re: Truely temporary variables
On Fri, Apr 15, 2005 at 11:45:16AM -0400, Aaron Sherman wrote:
: Among the various ways of declaring variables, will Perl 6 have a way to
: say, "this variable is highly temporary, and may be re-declared within
: the same scope, or in a nested scope without concern"? I often find
: myself doing:
:
: my $sql = q{...};
: ...do some DB stuff...
: my $sql = q{...};
: ...do more DB stuff...
:
: This of course results in re-defining $sql, so I take out the second
: "my", but then at some point I remove the first one, and strict chews me
: out over not declaring $sql, so I make it "my" again.
:
: This is a cycle I've repeated with dozens of variations on more
: occasions than I care to (could?) count.
And at that point, why not just change it to this?
my $sql;
$sql = q{...};
...do some DB stuff...
$sql = q{...};
...do more DB stuff...
It seems to me that assignment does a pretty good job of clobbering a
variable's value without the need to redeclare the container. If you
really want to program in a definitional paradigm that requires every
new definition to have a declaration, then you ought to be giving
different definitions different names, seems like, or putting each
of them into its own scope. Or write yourself a macro. Or just turn
off the redefinition warning...
It doesn't seem to rise to the level of a new keyword for me.
Larry
Re: Truely temporary variables
Aaron Sherman skribis 2005-04-15 11:45 (-0400):
> What I'd really like to say is:
> throwawaytmpvar $sql = q{...};
> throwawaytmpvar $sql = q{...};
I like the idea and propose "a", aliased "an" for this.
> It should probably be illegal to:
> throwawaytmpvar $sql = q{...};
> my $sql = q{...}; # Error: temporary became normal lexical
> or for that matter even give it a new type:
> throwawaytmpvar int $i = 0;
> throwawaytmpvar str $i = "oops"; # Error: redefinition of type
Giving it a new type should be valid. That is, I think the variable is
more useful if the old one is thrown away and a new one is created. This
can perhaps be optimized by re-using the same thing if it has no
external references anymore.
In fact,
a Str $foo = $foo;
is a nice way to indicate that from now on, you don't care about its
numeric value anymore.
All in all, I think a|an can just be my without warnings and then do
what you want.
Hm. Funny idea just occurred to me. What if something in ALLCAPS, or
better, just Ucfirst would disable all warnings for just that thing?
my $foo;
say $foo; # warning about undef $foo
Say $foo; # no warning
$closed_fh.print(Int($foo)); # just a warning about the closed fh
my $foo; # warning about new $foo masking first
My $foo; # no warning
If you think this looks much like PHP's @, you're right. It's not so bad
an idea, actually. The problem with PHP is that everything's a warning
and almost nothing actually dies.
No, Ucfirst it can't be, I think. And ALLCAPS is ugly. @ is taken (and
ugly). Suggestions?
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Macros [was: Whither "use English"?]
On Fri, Apr 15, 2005 at 12:45:14PM +1200, Sam Vilain wrote: : Larry Wall wrote: : > Well, only if you stick to a standard dialect. As soon as you start : > defining your own macros, it gets a little trickier. : : Interesting, I hadn't considered that. : : Having a quick browse through some of the discussions about macros, many : of the macros I saw[*] looked something like they could be conceptualised : as referring to the part of the AST where they were defined. : : ie, making the AST more of an Abstract Syntax Graph. And macros like : 'free' (ie, stack frame and scope-less) subs, with only the complication : of variable binding. The ability to have recursive macros would then : relate to this graph-ness. That is one variety of macro. : What are the shortcomings of this view of macros, as 'smart' (symbol : binding) AST shortcuts? The biggest problem with smart things is they're harder for not-so-smart people to understand. : The ability to know exactly what source corresponds to a given point on : the AST, as well as knowing straight after parse time (save for string : eval, of course) what each token in the source stream relates to is one : thing that I'm aiming to have work with Perldoc. I'm hoping this will : assist I18N efforts and other uses like smart editors. Yes, that's an important quality for many kinds of tools, whether documentation, debugging, or refactoring. : By smart editors, I'm talking about something that uses Perl/PPI as its : grammar parsing engine, and it highlights the code based on where each : token in the source stream ended up on the AST. This would work : completely with source that munges grammars (assuming the grammars are : working ;). Then, use cases like performing L10N for display to non- : English speakers would be 'easy'. I can think of other side-benefits : to such "regularity" of the language, such as allowing Programatica- : style systems for visually identifying 'proof-carrying code' and : 'testing certificates' (see http://xrl.us/programatica). Glad you think it's 'easy'. Maybe you should 'just do it' for us. :-) : macros that run at compile time, and insert strings back into the : document source seem hackish and scary to these sorts of prospects. We also allow (but discourage) textual substitution macros. They're essentially just lexically scoped source filters, and suffer the same problems as source filters, except for the fact that you can more easily limit the damage to a small patch of code. The problem is that the original patch of text has to be stored in the AST along with the new chunk of AST generated by the reparse, and it's not at all clear how a tool should handle that conflict. It's better to only parse once whenever possible, and just make sure the original text remains attached to the appropriate place in the AST. More basically, it's usually better to cooperate with the parser than to lie to it. : But then, one man's hackish and scary is another man's elegant : simplicity, I guess. : : * - in particular, messages like this: : - http://xrl.us/fr78 : : but this one gives me a hint that there is more to the story... I : don't grok the intent of 'is parsed' : - http://xrl.us/fr8a This is mostly talked about in the relevant Apocalypses, and maybe the Synopses. See dev.perl.org for more. Larry
Truely temporary variables
Among the various ways of declaring variables, will Perl 6 have a way to
say, "this variable is highly temporary, and may be re-declared within
the same scope, or in a nested scope without concern"? I often find
myself doing:
my $sql = q{...};
...do some DB stuff...
my $sql = q{...};
...do more DB stuff...
This of course results in re-defining $sql, so I take out the second
"my", but then at some point I remove the first one, and strict chews me
out over not declaring $sql, so I make it "my" again.
This is a cycle I've repeated with dozens of variations on more
occasions than I care to (could?) count.
What I'd really like to say is:
throwawaytmpvar $sql = q{...};
throwawaytmpvar $sql = q{...};
without problems. Of course, "throwawaytmpvar" is a bit long, but you
get the idea.
It should probably be illegal to:
throwawaytmpvar $sql = q{...};
my $sql = q{...}; # Error: temporary became normal lexical
or for that matter even give it a new type:
throwawaytmpvar int $i = 0;
throwawaytmpvar str $i = "oops"; # Error: redefinition of type
There might be other assumptions that this implies. For example, it
might be considered always thread-private and might be required to be a
core, unboxed type. These extra assumptions are only worth it if they
enhance the optimization possibilities surrounding such a value.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: $*CWD instead of chdir() and cwd()
On Fri, Apr 15, 2005 at 03:11:59AM -0700, Michael G Schwern wrote: : Error handling is simple, a failed chdir returns undef and sets errno. : : $CWD = $dir err die "Can't chdir to $dir: $!"; Offhand, I guess my main semantic problem with it is that if a chdir fails, you aren't in an undefined location, which the new value of $CWD would seem to indicate. You're just where you were. Then the user either has to remember that, or there still has to be some other means of finding out the real location. The other problem with it is the fact that people will assign relative paths to it and expect to get the relative path back out instead of the absolute path. : I encourage Perl 6 to adapt $*CWD similar to File::chdir and simply eliminate : chdir() and cwd(). They're just an unlocalizable store and fetch for global : data. Your assumption there is a bit inaccurate--in P6 you are allowed to temporize (localize) the effects of functions and methods that are prepared to deal with it. However, I agree that it's nice to have an easily interpolatable value. So I think I'd rather see $CWD always return the current absolute path even after failure, and temp chdir($dir) err fail "Can't chdir to $dir: $!"; be made to work as a temporizable function at some point, via the TEMP mechanism described in A4. Larry
Re: should we change [^a-z] to <-[a..z]> instead of <-[a-z]>?
On Fri, Apr 15, 2005 at 01:01:58PM -, Rafael Garcia-Suarez wrote: > Aaron Sherman wrote in perl.perl6.language : > > > > A silly question: is there a canonical character set from which we > > extract these ranges? Are we hard-coding Unicode here, or is there some > > way for the user to specify the character set for ranges? > > Perl 5 forces [a-z] (or [i-j] for that matter) to be a range of > lowercase alphabetic characters, even on EBCDIC platforms (where it's > not). At the moment, PGE (the part that implements the rule engine) is deferring such questions to Parrot, and otherwise assuming Unicode. Plus, S02 explicitly indicates that Perl is written in Unicode and has consistent Unicode semantics, so I think that's what we should go with. It's certainly the way the compiler will go, at least initially. Pm
Re: should we change [^a-z] to <-[a..z]> instead of <-[a-z]>?
Aaron Sherman wrote in perl.perl6.language : > > A silly question: is there a canonical character set from which we > extract these ranges? Are we hard-coding Unicode here, or is there some > way for the user to specify the character set for ranges? Perl 5 forces [a-z] (or [i-j] for that matter) to be a range of lowercase alphabetic characters, even on EBCDIC platforms (where it's not).
Re: should we change [^a-z] to <-[a..z]> instead of <-[a-z]>?
> > even sillier question: > if <[a.z]> matches "a", "." and "z" > and <[a...]> matches all characters from "a" including (for some > definition of 'all') > > how will be range \x21 .. \x2e written? > <[!..\.]>? (i.e. "." escaped?) > I was assuming from Larry's mail that <[a...]> would parse as either: 1) a character class containing the range from 'a' to '.' (what that means is a bit mind-bending for a friday afternoon) 2) a character class containing 'a' then a range from '.' to... oh, an error Which way might be ambiguous, but could of course be defined in the grammar. It hadn't occurred to me that ... for the range to infinity would be allowed or useful here. I suppose it could just mean 'up to the end of the available codepoints'. I do love the idea of <[a..f]> type ranges though. It's just what the three dots mean that's got me confused.
Re: <[]> ugly and hard to type
On Fri, Apr 15, 2005 at 02:58:44PM +0200, Juerd wrote:
> Am I the only one who thinks <[a-z]> is ugly and hard to type because of
> the nested brackets? The same goes for <{...}>. The latter can't easily
> be fixed, I think, but the former perhaps can.
Part of the thinking behind this is that the <[...]> construct
is likely to be less common in p6 rules than [...] was in p5 regular
expressions. For unicode reasons, one typically should be writing
instead of <[a-z]> anyway.
But yes, I understand the difficulty of typing <[...]> on non-US
keyboards. :-)
> \letter[] could well replace <[]>, and \LETTER[] would then replace
> <-[]>. This is consistent with many other \letters.
>
> "c" for character is taken
> "r" for range is taken by carriage return
> "a" for any is taken by alarm (bell)
> "l" for list is taken by lcfirst
Actually, \L[...] is gone -- see S05 and A05. I'm not sure if \a
exists, I haven't seen any reference to it in p6 rules. (One could
claim that it's carried over from p5, but rules are so far different
from regexes that I'm hesitant to make that assumption.) We could
certainly declare \a to be something else.
This isn't a vote from me either in favor or against this idea...
I'm just clarifying and making sure the discussion is up-to-date
with the relevant specs.
Pm
<[]> ugly and hard to type
Am I the only one who thinks <[a-z]> is ugly and hard to type because of
the nested brackets? The same goes for <{...}>. The latter can't easily
be fixed, I think, but the former perhaps can. If there are more who
think it needs to, that is. And <{}> is a bit easier to type because all
four are shifted (US QWERTY and US Dvorak), while with <[]> I really
have to think hard about when to press and when to release the shift
key.
\letter[] could well replace <[]>, and \LETTER[] would then replace
<-[]>. This is consistent with many other \letters.
"c" for character is taken
"r" for range is taken by carriage return
"a" for any is taken by alarm (bell)
"l" for list is taken by lcfirst
"m" is available, but I can't think of a mnemonic :)
\m[a..z] \M[a..z]
And to replace <[a..z]-[aoeui]> (does that construct even exist?),
[ \m[a..z] & \M[aoeui] ]. IMO, that's the only step backwards.
"a" would best communicate its function. Is the beep thing used enough?
(\cG still does that thing if \a is gone.)
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: should we change [^a-z] to <-[a..z]> instead of <-[a-z]>?
- Original Message - From: "Aaron Sherman" <[EMAIL PROTECTED]> To: "David Wheeler" <[EMAIL PROTECTED]> Cc: "Perl6 Language List" Sent: Friday, April 15, 2005 2:00 PM Subject: Re: should we change [^a-z] to <-[a..z]> instead of <-[a-z]>? > On Thu, 2005-04-14 at 21:32 -0700, David Wheeler wrote: > > On Apr 14, 2005, at 7:06 PM, Patrick R. Michaud wrote: > > > > > So, <[a.z]> matches "a", ".", and "z", > > > while <[a..z]> matches characters "a" through "z" inclusive. > > > > I was going to say that that was inconsistent, but since you never need > > to repeat a letter in a character class, well, I guess it isn't. But > > the first person to write <[a...]> gets what's comin' to 'em. > > A silly question: is there a canonical character set from which we > extract these ranges? Are we hard-coding Unicode here, or is there some > way for the user to specify the character set for ranges? > even sillier question: if <[a.z]> matches "a", "." and "z" and <[a...]> matches all characters from "a" including (for some definition of 'all') how will be range \x21 .. \x2e written? <[!..\.]>? (i.e. "." escaped?) braÅo
Re: should we change [^a-z] to <-[a..z]> instead of <-[a-z]>?
On Thu, 2005-04-14 at 21:32 -0700, David Wheeler wrote: > On Apr 14, 2005, at 7:06 PM, Patrick R. Michaud wrote: > > > So, <[a.z]> matches "a", ".", and "z", > > while <[a..z]> matches characters "a" through "z" inclusive. > > I was going to say that that was inconsistent, but since you never need > to repeat a letter in a character class, well, I guess it isn't. But > the first person to write <[a...]> gets what's comin' to 'em. A silly question: is there a canonical character set from which we extract these ranges? Are we hard-coding Unicode here, or is there some way for the user to specify the character set for ranges?
Re: should we change [^a-z] to <-[a..z]> instead of <-[a-z]>?
David Wheeler skribis 2005-04-14 21:32 (-0700): > I was going to say that that was inconsistent, but since you never need > to repeat a letter in a character class, well, I guess it isn't. But > the first person to write <[a...]> gets what's comin' to 'em. Given ASCII, <[\x20...]> would then be everything except control characters. Handy! By the way, does ...5 mean -Inf..5? ;) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
$*CWD instead of chdir() and cwd()
I was doing some work on Parrot::Test today and was replacing this code
with something more cross platform.
# Run the command in a different directory
my $command = 'some command';
$command= "cd $dir && $command" if $dir;
system($command);
I replaced it with this.
my $orig_dir = cwd;
chdir $dir if $dir;
system $command;
chdir $orig_dir;
Go into some new directory temporarily, run something, go back to the
original.
Hmm. Set a global to a new value temporarily and then return to the
original value. Sounds a lot like local. So why not use it?
{
local chdir $dir if $dir;
system $command;
}
But localizing a function call makes no sense, especially if it has side
effects. Well, the current working directory is just a filepath. Scalar
data. Why have a function to change a scalar? Just change it directly.
Now local() makes perfect sense.
{
local $CWD = $dir if $dir;
system $command;
}
And this is exactly what File::chdir does. $CWD is a tied scalar.
Changing it changes the current working directory. Reading it tells you
what the current working directory is. Localizing it allows you to
safely change the cwd temporarily, for example within the scope of a
subroutine. It eliminates both chdir() and cwd().
Error handling is simple, a failed chdir returns undef and sets errno.
$CWD = $dir err die "Can't chdir to $dir: $!";
I encourage Perl 6 to adapt $*CWD similar to File::chdir and simply eliminate
chdir() and cwd(). They're just an unlocalizable store and fetch for global
data.
As a matter of fact, Autrijus is walking me through implementing it in Pugs
right now.
Re: Hyper operator corner case?
John Williams wrote:
Good point. Another one is: how does the meta_operator determine the
"identity value" for user-defined operators?
Does it have to? The definition of the identity value---BTW, I like
the term "neutral value" better because identity also is a relation
between two values---is that $x my_infix_op $neutral == $x.
So the generic implementation that copies surplus elements is correct
with respect to the resulting value. You shouldn't expect the operator
beeing called as many times as there are elements in the bigger data
structure, though. It's called only for positions where both structures
have actual values. But that is the same as short-circuiting && and ||.
And somewhat the reverse of authreading from junctive values.
I believe the fine points fall out like this:
@a >>+<< 1# replicate
@a >>+<< (1) # replicate: (1) is still scalar
@a >>+<< [1] # extend: [1] is an array (and will auto-deref)
I think they fall out naturally from typing and dispatch. But note
that the » « operator has three args. I haven't made the &op a dispatch
selector. If the my_infix_op from above needs to handle neutral elements
by itself just tell the dispatcher by defining
&infix_circumfix_meta_operator:{'»','«'}:(List,List,&my_infix_op:) and
construct the neutral elements when one of the list runs out of elements.
I hope the syntax I used does what I want to express. Note that in
:(List,List,&my_infix_op:) the first two elements are types while
&my_infix_op is a sub value. In that sense my &op was actually wrong
but it was nice for wording my sentence. So the generic name should read
&infix_circumfix_meta_operator:{'»','«'}:(List,List:Code) or perhaps
&infix_circumfix_meta_operator:{'»','«'}:(List,List:&) if & is considered
as the code sigil. Hmm, then we could also have :(@,@:&) meaning the
same type spec?
BTW, starting from these type specs I come (back) to the suggestion of using
» « for hypering function calls and/or their arguments. Has that been decided?
I'm not sure if specialisation on values is covered by the :() syntax.
E.g. one could implement &infix:<*>:(0,Any) to return 0 without evaluating
the Any term at all! But this needs either lazy evaluation in the functional
paradigma or code morphing 'x() * y()' to '(($t = x()) != 0) ?? $t * y() :: 0'
or some such. On assembler level this morphing reduces to an additional
check of a register for zero. But I'm not sure if the type system and the
optimizer will be *that* strong in the near future ;)
Regards
--
TSa (Thomas Sandlaß)
