On Sun, Jul 11, 2004 at 11:06:30PM -0400, Jonadab the Unsightly One wrote:
: Larry Wall <[EMAIL PROTECTED]> writes:
:
: > No, just currently wrong. :-) I changed my mind about it in A12,
: > partly on the assumption that $object.attr would actually be more
: > common than $file.ext,
:
: Speaking of which, what's the cleanest way to interpolate filenames
: with a fixed extension now? "${file}.ext" ? "$file\.ext" ?
Cleanliness is a relative concept, but I'd tend to go with the
backslash in this case.
Another alternative is "$( $file ).ext". I'd tend to use that before
"${file}.ext" these days. Perhaps that's irrational--but it was hard
to get the special-case "${name}" form to work right in the Perl 5
lexer, and that bugs me. If we're going to get rid of the autoquoting
of $hash{shift}, we likely ought to undo the autoquoting of ${shift}
as well, even if that gives heartburn to a certain number of shell
programmers.
: Also, I guess that if "$foo.bar" is taken as a method call, then
: "$file.$ext" is going to be trouble also, is that right? An error?
: Or will it treat the value of $ext as the name of a method, or maybe
: look for a method starting with $ ?
It will use the value of $ext as the name of the method. Alternately,
we could simply disallow indirect method names inside interpolations.
They're very rare, and you could always say $( $file.$ext ) in that case.
: > but also because a bogus method call is likely to be noticed sooner
: > than bad output data, and because noticing goofs sooner rather than
: > later is often construed to be a good thing. (Though this attitude
: > can be taken to extremes--see static typing.)
:
: Quite. Perl6 is last I checked moving in the direction of giving a
: more informative error message later, rather than a syntax error
: sooner, which IMO is a good thing. Not that this is a case of that,
: but it demonstrates that noticing sooner isn't necessarily always the
: best way to go. (Static typing is certainly an annoying limitation,
: and I'm sure there are other examples.)
One error message that would be of great benefit to novices is if we
could guess where the missing brace is based on indentation. (But not
*assuming* the missing brace, of course--this isn't Python... :-)
: However, while it's a shame not to be able to interpolate "$file.ext",
: I can certainly see the argument for "$object.method" being a common
: case, one that I imagine I'll use quite often.
It's also a philosophical issue of making trying to make $object.method
look and behave exactly like a variable. This carries through to several
other design decisions, such as allowing "temp $object.method".
: Of course, this leaves open the question of whether there are any
: fairly common filename extensions that happen to be spelled the same
: as a method on Perl6's string class, that might ought to have a
: warning generated... Are there any three-letter methods on the
: string class? (Maybe there shouldn't be, in the core language...)
Yes. We might also need to be careful about doing failover from
$foo.bar(1) to bar($foo,1). Otherwise any multimethod that allows a
string as the first argument could also be confused with an extension.
I suppose another approach is simply to declare that dot is always a
metacharacter in double quotes, and you have to use \. for a literal
dot, just as in regexen. That approach would let us interpolate
things like .foo without a variable on the left. That could cause
a great deal of cultural confusion in the short term, however.
On the other hand, that raises the issue of what this should match:
/$foo.bar/
and if we let people interpolate .bar into strings, then what will they
expect this to do:
/.bar/
Ouch. I'm thinking we allow $foo.bar in both strings and regexen, but
not .bar in either case. Gotta use $_.bar inside strings and regexen.
(Or $(.bar) would work too.) Possibly we even complain about /.bar/
and force them to write /. bar/.
Likewise, /$foo.$bar/ should probably also be forcibly disambiguated
to either /$( $foo.$bar )/ or /$foo . $bar/.
Larry
