Re: String interpolation
On Sat, 24 Jul 2004, Jonadab the Unsightly One wrote:
As a related side note, is it possible to use multi-char delimiters in
Perl6? I mean, a la:
qq...;
I would worry that you'd be getting and at the beginning and
end of your string. IMO, there are enough characters in ASCII that
for any short quotation you ought to be able to find one character you
can use as a quote delimiter. For longer quotations, we have
heredocs.
Of course, and in this respect my choice for an example was most probably
not the best appropriate one, still, in view of all this huffmanization
phylosophy, it occurs to me that just as one should avoid (at least in
Perl5) // as delimiters in regexes if he has to match some literal /'s,
it would be sensible to allow, say qq((...)), to have a different meaning
from qq/(...)/ because should one have needed the latter, he would have
used it in the first place and this may leave another possibly more
interesting use for the former...
Speaking of which, that raises another question: can we apply adverbs
to heredocs?
if (somecondition()) {
$foo = :indent(5) FOO;
FWIW I, for one, would regard this as Very Cool(TM). This is yet another
thing that may be done in many other ways, but a similar adverb would
greately simplify one's life!
Michele
--
Ah, but the REAL myster is -- did Pythagoras really discourage eating
beans because they resembled human testicles? Or is that another myth?
I always thought it was because of their musical qualities.
- Robert Israel in sci.math (slightly edited)
Re: String interpolation
On Sat, 24 Jul 2004, Larry Wall wrote: This particular modeful behavior is easily handled by most current editors. You have to be able to treat the insides of strings different from the outsides. That being said, there are plenty of other things in Perl 6 already that will drive editors nuts. This just isn't one of them. Also, only perl can parse Perl, and I don't think this will change with Perl6... anyway FWIW there are only 1.5 circumstances in which my editor (jed) regularly bugs me when writing perl code... Michele -- I find the line I am not pestering anybody, I am asking questions on usenet. That's what usenet is for. a classic. It's like I am not talking to you, I am just opening and closing my mouth while standing close to you. That's what a mouth is for. - David Kastrup, on comp.text.tex (slightly edited)
Re: String interpolation
On Tue, Jul 27, 2004 at 12:44:09PM +0200, Michele Dondi wrote: On Sat, 24 Jul 2004, Larry Wall wrote: This particular modeful behavior is easily handled by most current editors. You have to be able to treat the insides of strings different from the outsides. That being said, there are plenty of other things in Perl 6 already that will drive editors nuts. This just isn't one of them. Also, only perl can parse Perl, and I don't think this will change with Perl6 I think it will. Or the definition of perl will change slightly. I think Perl6 will have sufficient hooks such that other languages (or editors) will have complete access to perl's parsing ability via a library (for instance. maybe it's via some other mechanism) such that anything could parse perl if it knows how to ask. :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: String interpolation
Larry Wall [EMAIL PROTECTED] writes:
On Tue, Jul 20, 2004 at 11:00:39PM -0700, chromatic wrote:
: On Tue, 2004-07-20 at 19:35, Luke Palmer wrote:
:
: The New Way (tm) to do that would probably be sticking a role onto the
: array object with which you're dealing:
:
: my @foo does separator('//') = (1,2,3,4,5);
: say [EMAIL PROTECTED]; # 1//2//3//4//5
:
: Shh, no one's let slip the idea of curried roles yet! I'm not even
: certain A12 mentioned parametric roles, let alone first-class roles.
Well, A12 did talk about parametric roles, but I glossed over the
first-class roles a bit. I didn't want to scare people with
$foo does $bar
though, of course, there's no reason in principle you shouldn't be able
to do that as a run-time operation. You just can't instantiate a role
object. The murky area in the middle is, of course, how you specify
an initial value aimed at the attributes of a particular role without
creating a real object containing just those values. Passing around
lists of pairs is probably good enough for that, as long as you can
keep straight which list of pairs is intended to initialize which
roles.
I really hope you change your mind about this; the sooner I can get
that wild and crazy list of pairs nicely stashed in their appropriate
role objects, the happier I'll be about the resilience of my code.
Re: String interpolation
Damian Conway [EMAIL PROTECTED] writes:
I can't say I'm keen on making {...} special in strings. I felt that the
$(...) and @(...) were a much cleaner and more general solution. The
prospect of backslashing every opening brace in every interpolated
string is not one I relish.
Maybe we could write macros to provide a Lispish 'metaquoted'
environment for when one is writing template code which wouldn't
interpolate *anything* unless it was in C$(...) or C@(...).
Re: String interpolation
On 7/21/04, Brent 'Dax' Royal-Gordon wrote: Amen. Please don't steal unnecessary metacharacters in qq() strings--although I still think we should keep it, @ causes a lot of problems. That's why my suggestion would be to use a character that already has a special meaning in double-quoted strings: . Well, we probably need a bit more than that, so maybe ~ and ~ for scalar context or , and , for list context, or some such. No new metacharacters and you could put just about anything -- hashes, subs, small island nations -- inside the ~...~! Actually, I've been pondering this incessant urge to interpolate -- I have to admit, I suffer from it as much as anyone, but when I ask myself why, I can't come up with a good answer. Being able to stick a simple $foo in a string is great, but sometimes I catch myself interpolating when, uh, extrapolating would not only be much more readable, but occasionally it would even mean less typing. At any rate, I'm leaning more and more to the sparse, simple proposals (the ones that I might actually be able to remember). Normally, I'm all for cramming everything into The Core(TM) up to and including Sinks::Kitchen on the grounds that if you don't like it, you don't hafta use it. However, this doesn't apply to the rules for interpolation because even if I decide that I'll never interpolate anything anywhere, I still have to remember what all the rules are so I don't forget to escape the right things. Hm, every time I go to post this, I think of something else. Now I'm recognising that I've been labouring under a false dichotomy: we don't have to have simple rules for interpolation OR complex rules. This is Perl, why can't we have both ways to do it? q// -- no interpolation qq// -- moderate interpolation: $foo, @bar[$none], %bat«man» qqq// -- ultimate interpolation: anything not A-z0-9 has a special meaning =) Except it's probably qi instead of qqq, or maybe qq does lots of interpolation and the new guy does less. And q, qq, qqq, ', , , etc. are probably all just abbreviations for quote :various :interp :adverbs anyway. I was also going to say something tongue-in-cheek about Unicode quotation marks, but curly-quotes could actually be quite useful. They're a twistier, more complex version of plain old straight quotes, but most interestingly they come in left-handed and right-handed versions. So you might nest them to indicate alternating literal and interpolated values. Erm... or maybe not. But I'm sure there's some way to put them to good use. - David ³wondering how likely curly-quotes are to come out right² Green
Re: String interpolation
David Green wrote: I was also going to say something tongue-in-cheek about Unicode quotation marks, but curly-quotes could actually be quite useful. Reasons not to use them as anything but synonyms for normal double quotes: 1) They look too much like each-other. 2) They look too much like normal quotes. 3) Some editors will give you one when you want the other. - David ³wondering how likely curly-quotes are to come out right² Green 4) Many people think they're in Latin-1, but they aren't, they're only in Microsoft's perversion of Latin-1. -=- James Mastros
Re: String interpolation
Michele Dondi [EMAIL PROTECTED] writes:
Well, it seems that there's still a big confusion/indecision about
the default behaviour. But then an interesting point, and one that
has already been raised, is that it should be somehow possible to
customize string interpolation bu means of e.g. adverbs (fortunately
we don't have true literal strings but rather quote-like
operators), attributes and god know what else!
I rather like the notion of putting the adverb on the q operator and
its kin (qq, qx, ...)
print q :literal The value of $foo is . $foo . \n;
:literal might be poorly huffman coded, and q (as opposed to qq or
whatever) might already default to not interpolating scalars, but the
above demonstrates the syntax. One nice thing about this is it still
allows for arbitrary characters to be used to delimit the quote:
print qq :scalarcontext (There are @foo elements in [EMAIL PROTECTED]);
Again, :scalarcontext isn't the point, just an illustration of the syntax.
This syntax also would give us symetry with the match operators...
$foo = qr :baz !blah$!;
$bar =~ m :quux $foo; # I forget: is =~ still spelled as in Perl5?
Here also, with qr you could use whatever adverbs you use with any of
its brethren quoting operators, to interpolate or not interpolate
various stuff, and then you could still use whatever pattern-match
adverbs you like with the match operator.
Now it should be stressed that the problem is twofold here: one
aspect is chosing the best default for some hopefully reasonable
meaning of best
Sure, but allowing the default to be overridden with adverbs doesn't
hinder the ability to choose a nice default.
and the other one is providing a slim syntax for the alternate
behaviour(s); i.e. IMHO it would be unreasonable to require the
users to type something like
:with_method_interpolation
One would hope an adverb that useful would be shorter, sure. Maybe
something along these lines, if we can conscion it...
$foo = qq :i($) Woo $hoo;
$bar = qq :i@ . ($boo.hoo @wibble);
Here i stands for interplate, $ for scalars, @ for arrays, . for
methods. If this is deemed too cryptic, perhaps something in between
this and the excessive verbosity of :with_method_interplation is in
order.
It's slightly bothersome that :i would mean interplate for quoting
but case-insensitive for matching, but since case-insensitivity
doesn't seem sensible for quoting that might not matter. I thought
about :int for interpolation, but too many people would think integer,
probably, and :itpl is just too C-like in its unpronounceability and
complete lack of obvious meaning. (What's an i-tuple?) :terp or
:iterp would make people think interpreter rather than
interpolate, I fear, and when we move up to :terpolate we're getting
long. The only synonym I can think of for interpolate is evaluate,
and I'm not certain :eval would mean the right thing to everyone.
each time they want it. But maybe certain delimiters for qq may
already provide that... (or would that be a bad idea?)
I don't think which _delimiters_ you choose should have any impact on
how the interpolation is done (except as regards the delimiters
themselves; if you choose $ as your delimiter, you're going to have a
hard time interplating scalars, obviously).
IMO, the difference between q and qq should have to do with which
adverbs are turned on by default.
As a related side note, is it possible to use multi-char delimiters in
Perl6? I mean, a la:
qq...;
I would worry that you'd be getting and at the beginning and
end of your string. IMO, there are enough characters in ASCII that
for any short quotation you ought to be able to find one character you
can use as a quote delimiter. For longer quotations, we have
heredocs.
Speaking of which, that raises another question: can we apply adverbs
to heredocs?
if (somecondition()) {
$foo = :indent(5) FOO;
blah, blah
blah, blah
blah, blah
FOO
}
Parsing concerns might constrain that to this:
if (somecondition()) {
$foo = :indent(5) FOO;
blah, blah
blah, blah
blah, blah
FOO
}
Which is still better than the bletcherous Perl5 way:
if (somecondition()) {
$foo = FOO;
blah, blah
blah, blah
blah, blah
FOO
}
I've found myself wrapping long quotations in their own subroutines
(that just contain a heredoc and return a string) at the bottom of the
file in Perl5 just to keep my indentation sane. There ought to be
some way around this problem for POD, too. Perhaps POD could have its
own quote operator...
sub foo {
qp :indent(5) FOOPOD;
Put some POD here.
FOOPOD
...
}
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: String interpolation
Correct me if I'm wrong, but, by analogy with $foo.bar(), ...
No Yes
-- ---
@foo@foo[1]
%bar%bar{a} or %bar«a»
$foo.bar$foo.bar()
foofoo(1)
@foo@foo.join( )
Yes?
/me idly wonders whether map and grep and sort could be made into
methods on the array class and chained together and interplated as
such...
print @foo.map({[$_,wibble($_)]}).sort([EMAIL PROTECTED] cmp @$b[1]}).map([EMAIL
PROTECTED]);
Ugh, that looks horrible. Of course, one could probably define a
.schwartz() method on the array class and do the above thusly...
print @foo.schwartz({wibble($_)},{$a cmp $b});
That doesn't buy you the flexibility to throw in extra steps (like a
grep in the middle), but it sure is easier to read.
Of course one could argue that sensible people would assign the
processed list to an array variable first and then interplate that...
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: String interpolation
Johan Vromans [EMAIL PROTECTED] writes:
Larry Wall [EMAIL PROTECTED] writes:
: my $d=a;
: print --$d--{my $d = b }--$d--\n;
Yes, that is correct.
I'm afraid things like this will keep many popular editors and IDEs
from implementing perl6 support...
Then maybe people will switch to more capable editors.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: String interpolation
On Sat, Jul 24, 2004 at 12:08:24PM -0400, Jonadab the Unsightly One wrote:
: Johan Vromans [EMAIL PROTECTED] writes:
:
: Larry Wall [EMAIL PROTECTED] writes:
:
: : my $d=a;
: : print --$d--{my $d = b }--$d--\n;
:
: Yes, that is correct.
:
: I'm afraid things like this will keep many popular editors and IDEs
: from implementing perl6 support...
:
: Then maybe people will switch to more capable editors.
This particular modeful behavior is easily handled by most current
editors. You have to be able to treat the insides of strings different
from the outsides. That being said, there are plenty of other things
in Perl 6 already that will drive editors nuts. This just isn't one
of them.
As for IDEs, any decent IDE is going to have hooks directly into the
language's parser.
Larry
Re: String interpolation
On Sat, Jul 24, 2004 at 11:59:30AM -0400, Jonadab the Unsightly One wrote:
:
: Correct me if I'm wrong, but, by analogy with $foo.bar(), ...
:
: No Yes
: -- ---
: @foo@foo[1]
: %bar%bar{a} or %bar«a»
: $foo.bar$foo.bar()
: foofoo(1)
: @foo@foo.join( )
:
: Yes?
Yes, that would presumably work.
: /me idly wonders whether map and grep and sort could be made into
: methods on the array class and chained together and interplated as
: such...
:
: print @foo.map({[$_,wibble($_)]}).sort([EMAIL PROTECTED] cmp @$b[1]}).map([EMAIL
PROTECTED]);
:
: Ugh, that looks horrible. Of course, one could probably define a
: .schwartz() method on the array class and do the above thusly...
:
: print @foo.schwartz({wibble($_)},{$a cmp $b});
:
: That doesn't buy you the flexibility to throw in extra steps (like a
: grep in the middle), but it sure is easier to read.
Well, on that specific topic I'd suggest going back and looking at
the sort syntax thread we had several months ago. What we ended up with
has ST built in, among other things.
: Of course one could argue that sensible people would assign the
: processed list to an array variable first and then interplate that...
There are any number of syntactic constructs that people can abuse.
It's actually pretty rare that I get a bee in my bonnet about one of
them and place arbitrary limits. I do that with statement modifiers
and with required braces on blocks.
Larry
Re: String interpolation
On Thu, Jul 22, 2004 at 11:16:09AM -0500, Dan Hursh wrote:
: Larry Wall wrote:
: No Yes
: -- ---
: @foo@foo[1]
: %bar%bar{a} or %bar«a»
: $foo.bar$foo.bar()
: foo foo(1)
:
: I may have missed it, but what are the contexts in these cases? I'm
: thinking the first two are easily scalar. Are the second list just as
: if they were inside curly braces, or are the scalar to match the others
: (or just to be flexibly different)?
I tend to like the flexibly different approach. On the other hand,
that doesn't say what to do if such a method or sub actually returns a
list in scalar context, and whether that's the same thing that would
happen inside curlies. We could distinguish those, rather like Perl
5 distinguishes these:
print @foo,\n;
print @foo,\n;
People certainly learned to deal with that little non-orthogonality.
On the other hand, it might be viewed as gratuitously fiddly to make
print @x.sort()\n;
print [EMAIL PROTECTED];
interpolate differently. I don't profess to have an opinion on it yet.
: In this worldview, $foo is an exception only because it doesn't naturally
: have a form that ends with some kind of bracket.
:
: Will $x[$y] interpolate?
Certainly. Likewise $x{$y}. (Presuming we keep the end bracket rule.)
: Oh and if $x is a reference to an array, is
: $x a stringified reference or dereferenced (and in which context)?
In any string context, the default will be to dereference references
to a real value. That includes list contexts embedded within a string
context, as bare {} would supply. The main question is when to get
fiddly about supplying spaces between the values.
: I got it in my head that since things in curlies would be in list context
: that the others must be scalar/string context.
They're all ultimately in string context, but curlies would do it
via list context. It would make no difference for functions that
always return scalars in list context, and little to no difference for
functions that always return lists regardless of context (depending
on how we fiddle it).
: I haven't been able to
: find a reason for justifing that leap, but I kind of like it. Well for
: the moment.
Yeah, me too...this week...
Larry
Re: String interpolation
On Thu, Jul 22, 2004 at 11:12:16PM +0100, Dave Mitchell wrote:
: On Wed, Jul 21, 2004 at 04:37:29PM -0700, Larry Wall wrote:
: We allowed/required @foo to interpolate in Perl 5, and it catches a
: certain number of people off guard regularly, including yours truly.
: So I can argue [EMAIL PROTECTED] both ways.
:
: Currently @foo[] is a syntax error. maybe @foo[] in Perl6 could be
: what @foo is in Perl5? And I mean a literal '[]', not
: @foo[expression-that-returns-an-empty-list]
Well, I can argue that one both ways too. It's certainly recognizable
as some kind of undifferentiated subscript, but it has two distinct
interpretations, unfortunately. The null list inside could either
be considered to be a zero-dimensional subscript, or a one-dimensional
subscript that happens to be a null slice.
If you take the former interpretation, it makes sense that @foo[]
means the whole array as the limiting case:
@foo[3;2;1], @foo[3;2], @foo[3], @foo[]
If you take the latter, it makes sense that @foo[] means none of
the array:
@foo[1,2,3], @foo[1,2], @foo[1], @foo[]
A code generator could come up with either of those as a limiting case
and reasonably expect either everything or nothing. What the user
expects will probably depend also on the declared dimensionality of
the object. (Similar considerations apply to %foo{}.) So we have to
penalize one syntax or the other. Either we force the user to say
something like
@foo[*]
to indicate that the first subscript is to be considered a Zen
slice (make me one with everything) or we force them to say
@foo[()]
to indicate that the first subscript is to be considered an empty
slice. You just can't have it both ways. Certainly there seems
to be a lot more utility in arrays with everything in them rather
than nothing, so I'm inclined to bias it in favor of @foo[] returning
the entire array, especially if we go with the end bracket rule.
Larry
Re: String interpolation
On Thu, Jul 22, 2004 at 03:33:01PM +0200, Michele Dondi wrote: : But then an interesting point, and one that has already : been raised, is that it should be somehow possible to customize string : interpolation bu means of e.g. adverbs (fortunately we don't have true : literal strings but rather quote-like operators), attributes and god know : what else! It has always been my intent to extend the rx:foo// model to qq:foo// and the like. Larry
Re: String interpolation
Larry Wall wrote:
Actually, I've been rethinking this whole mess since last week, and
am seriously considering cranking up the Ruby-o-meter here just a tad.
At the moment I'm inclined to say that the *only* interpolators in
double quotes are:
\n, \t etc.
$foo
@foo[$i]
%foo{$k}
{EXPR}
where the last provides a list context to EXPR. So all of these
would require curlies:
{foo()}
[EMAIL PROTECTED]
{%foo}
{$foo.bar}
{Dog.wag}
{.count}
{~localtime}
[EMAIL PROTECTED]
[EMAIL PROTECTED] '.'}
{$x.as %10.5d}
This is close to the new form() syntax as well, which could be
considered a plus. I for one won't complain about adding the good things
from Ruby back in to Perl.
matt
Note that this not only fixes the Perl 6 % in sprintf issue, but
also the Perl 5 @ in email address issue. It also generalizes the
notion that curlies (almost) always indicate a closure everywhere.
On the other hand, it undoes my stated A12 policy that $x.foo can be
used anywhere $foo can. On the gripping hand, it enables {.foo}
where we would have had a lot of $_.foo, and I think that's an
improvement in readability, at least for people who believe in topics.
Larry
Re: String interpolation
Larry Wall [EMAIL PROTECTED] writes:
: my $d=a;
: print --$d--{my $d = b }--$d--\n;
Yes, that is correct.
I'm afraid things like this will keep many popular editors and IDEs
from implementing perl6 support...
-- Johan
Re: String interpolation
Matt Diephouse skribis 2004-07-20 20:06 (-0400): This is close to the new form() syntax as well, which could be considered a plus. I for one won't complain about adding the good things from Ruby back in to Perl. Ehm, no, that means that if you want to interpolate something into the format string, the rest of that string becomes bizarrely unreadable. Juerd
Re: String interpolation
On Tue, 20 Jul 2004, Damian Conway wrote:
Larry wrote:
Actually, I've been rethinking this whole mess since last week, and
am seriously considering cranking up the Ruby-o-meter here just a tad.
[snip]
I can't say I'm keen on making {...} special in strings. I felt that the
$(...) and @(...) were a much cleaner and more general solution. The
prospect of backslashing every opening brace in every interpolated
string is not one I relish.
Well, it seems that there's still a big confusion/indecision about the
default behaviour. But then an interesting point, and one that has already
been raised, is that it should be somehow possible to customize string
interpolation bu means of e.g. adverbs (fortunately we don't have true
literal strings but rather quote-like operators), attributes and god know
what else!
Now it should be stressed that the problem is twofold here: one aspect is
chosing the best default for some hopefully reasonable meaning of best
and the other one is providing a slim syntax for the alternate
behaviour(s); i.e. IMHO it would be unreasonable to require the users to
type something like
:with_method_interpolation
each time they want it. But maybe certain delimiters for qq may already
provide that... (or would that be a bad idea?)
As a related side note, is it possible to use multi-char delimiters in
Perl6? I mean, a la:
qq...;
Michele
--
But seriously this (Godwin's law) painting one's rhetorical
opponents as Nazis is an odious and verminous ploy normally used,
as here, to mask the intellectual bankruptcy of one's arguments.
- Robin Chapman in sci.math, Die Petry, die: was Re: Die Cantor Die
Re: String interpolation
On Wed, Jul 21, 2004 at 04:37:29PM -0700, Larry Wall wrote: We allowed/required @foo to interpolate in Perl 5, and it catches a certain number of people off guard regularly, including yours truly. So I can argue [EMAIL PROTECTED] both ways. Currently @foo[] is a syntax error. maybe @foo[] in Perl6 could be what @foo is in Perl5? And I mean a literal '[]', not @foo[expression-that-returns-an-empty-list] Dave -- You never really learn to swear until you learn to drive.
Re: String interpolation
Larry Wall wrote:
No Yes
-- ---
@foo@foo[1]
%bar%bar{a} or %bar«a»
$foo.bar$foo.bar()
foofoo(1)
I may have missed it, but what are the contexts in these cases? I'm
thinking the first two are easily scalar. Are the second list just as
if they were inside curly braces, or are the scalar to match the others
(or just to be flexibly different)?
In this worldview, $foo is an exception only because it doesn't naturally
have a form that ends with some kind of bracket.
Will $x[$y] interpolate? Oh and if $x is a reference to an array, is
$x a stringified reference or dereferenced (and in which context)? I
got it in my head that since things in curlies would be in list context
that the others must be scalar/string context. I haven't been able to
find a reason for justifing that leap, but I kind of like it. Well for
the moment.
Dan
Re: String interpolation
On Wed, Jul 21, 2004 at 04:37:29PM -0700, Larry Wall wrote:
No Yes
-- ---
@foo@foo[1]
%bar%bar{a} or %bar«a»
$foo.bar$foo.bar()
foo foo(1)
In this worldview, $foo is an exception only because it doesn't naturally
have a form that ends with some kind of bracket.
In an ideal universe, here's what I would like to see:
Scalars and things ending in brackets are interpolated. Things
starting with '@' are interpolated if there is an array of that name,
otherwise they are treated as literals.
$foo = 'apple';
%bar = ('a', 1, 'b', 2);
@foo = a b c;
sub foo { my $param = shift // 7; return $param +2; }
# attached to object $baz which stringifies to '^object baz^'
method bar { return 'quux'; }
print $foo; # apple
print \$foo; # $foo
print %bar; # %bar
print $baz.bar; # ^object baz^.bar
print $baz.bar(); # quux
print $baz\.bar();# ^object baz^. with WARNING: no function bar()...
print foo; # foo
print foo(); # 9
print foo(); # 9
print foo(1);#
print @foo[1];# a
print %bar{'a'}; # 1
print %bar«a»;# 1
print @foo; # a b c [1]
undef @foo;
print @foo; # @foo [2]
[1] Variable @foo exists, so it is interpolated. Separator character
might or might not be space, null string, whatever.
[2] Variable @foo does not exist, so is used as literal value,
possibly with warning. I don't know if there would be a difference
between these:
undef @foo
delete ::{'@foo'} # Perl5 syntax...still correct?
If there is, then probably the latter is required.
--
[EMAIL PROTECTED]
Re: String interpolation
On Tue, 2004-07-20 at 19:35, Luke Palmer wrote:
The New Way (tm) to do that would probably be sticking a role onto the
array object with which you're dealing:
my @foo does separator('//') = (1,2,3,4,5);
say [EMAIL PROTECTED]; # 1//2//3//4//5
Shh, no one's let slip the idea of curried roles yet! I'm not even
certain A12 mentioned parametric roles, let alone first-class roles.
-- c
Re: String interpolation
Luke Palmer wrote:
I admit there's a certain interest to Larry's new idea. I've been
looking for more distinction between $, @, and % in Perl 6, since they
start to become mostly irrelavent. In the new proposal:
my @a = (1,2,3,4,5);
my $a = @a;
say @a; # @a
say $a; # 1 2 3 4 5 (perhaps?)
I think that's a bad kind of distinction, personally. It breaks an
obvious parallel.
But I'll admit that I'm much more a fan of $() and @() than I am of {}.
Form.pm would get very angry at this decision indeed.
Amen. Please don't steal unnecessary metacharacters in qq()
strings--although I still think we should keep it, @ causes a lot of
problems.
On the other hand, this is another step unifying strings and regexes. I
can say pretty confidently that that's a Good Thing.
The equivalent regex syntax isn't interpolating, even to the extent that
a bare $foo or @bar is, so this would be sort of a false cognate--IMHO
another reason not to have interpolating {}.
and what about @a[1]('arg')[3]?
That probably wouldn't.
Actually, I have to wonder why foo('bar', 'baz') wasn't on Larry's
list. Is there a reason for that?
(On the other hand, what will happen with HTML entities like nbsp; or
copy; if that *is* allowed?)
The New Way (tm) to do that would probably be sticking a role onto the
array object with which you're dealing:
my @foo does separator('//') = (1,2,3,4,5);
say [EMAIL PROTECTED]; # 1//2//3//4//5
I would think you'd use a property:
my @foo = (1,2,3,4,5) but separator('//');
Or maybe a trait:
my @foo is separated('//') = (1,2,3,4,5);
Or perhaps even a (gasp!) attribute:
my @foo = (1,2,3,4,5);
@foo.separator='//';
Roles are nice, but don't forget about the other mechanisms in Perl for
such things.
[Forgot to send it to the list. D'oh.]
[And then I sent it to the wrong one. D'oh * 2.]
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: String interpolation
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Amen. Please don't steal unnecessary metacharacters in qq()
strings--although I still think we should keep it, @ causes a lot of
problems.
I seem to recall an issue, last week, of whether adverbs can be attached to
quoting operators. One solution to the question of interpolation is to make
it user-customizable, and then throw in some currying to keep life
interesting:
my $email_address = qq([EMAIL PROTECTED]) : interpolates( :yes('$'), :no('@') );
There's probably a better syntax for defining what actually interpolates.
Anyway, whatever the syntax, it should then be possible to create my own
quoting operator with exactly the properties I want:
my email := qq.assuming( : interpolates( :yes('$'), :no('@') ) );
and then
my $email_address = email([EMAIL PROTECTED]);
This could also be implemented as a macro, but that shouldn't be necessary.
A good, spicy, adverbial curry should be sufficient.
Dave.
Re: String interpolation
Chromatic [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Shh, no one's let slip the idea of curried roles yet! I'm not even certain A12 mentioned parametric roles, let alone first-class roles. And with parametric roles, perhaps we also get Cmulti roles? Dave.
Re: String interpolation
On Tue, Jul 20, 2004 at 09:20:56PM -0400, Damian Conway wrote:
: So what about:
:
: $foo[$i]
: $foo{$k}
:
: ???
Those would work.
: And would slices interpolate?
Yes. Slices are entirely determined by what's in the subscript.
: I can't say I'm keen on making {...} special in strings.
It had to grow on me a while too.
: I felt that the $(...) and @(...) were a much cleaner and more
: general solution.
Yeah, I felt that way too. But then I start looking at teaching people
the subtle difference between
${} $()
@{} @()
%{} %() ?
{} () ???
and realize that this is the only holdover from Perl 5 where we use
the sigil to indicate the internal context rather than the type of
the object expected. It's a danger sign that we have to keep repeating
ourselves (or not, as the case may be):
$($foo)
@(@foo)
$(@foo)
Plus it ignores the fact that we've already introduced single character
scalar context operators that make it trivial to coerce from list
context to scalar. If {...} supplies list context by default, most
intepolations are either the same length or shorter:
$($foo) {$foo}
@(@foo) [EMAIL PROTECTED]
$(@foo) [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
It also encourages people be more specific about *which* scalar
context they're looking for. It fits in with the general trend in Perl 6
that the default context is list context if you don't know better.
Plus, as I mentioned, it cleans up the $file.ext mess, the
[EMAIL PROTECTED] mess, and the %08x mess. That's three FAQs that
don't have to exist.
: The prospect of backslashing every opening brace in every interpolated string
: is not one I relish.
I'm just looking for what will be least confusing to the most
people here. We can certainly have other possible behaviors, but
something simple needs to be the default, and $() doesn't feel right
to me anymore.
Larry
Re: String interpolation
On Wed, Jul 21, 2004 at 06:25:46AM +0400, Alexey Trofimenko wrote:
: some questions:
:
: 1) is @a[1][2]{'a'}«b» interpolateable?
Yes.
: and what about @a[1]('arg')[3]?
I can argue that both ways, but overall it seems like it won't cause
much of a problem, and keeps () in the same mental category as []
and {}. So probably yes.
: 2) what's the default separator for list interpolation?
: {1,2,3} eq 123 or
: {1,2,3} eq 1 2 3 ?
Space would be what a Perl 5 programmer would expect, and is often what
you want. Though there's also an argument that the default should
be [1,2,3]. But I think we need to force use of a .repr for that.
: and is there any way to redefine it, as assigment to perl5 @ does?
You mean $, I presume. We had said that the default interpolation
separator could be set as a trait of an array. That's a bit of a
problem if the array only knows it's being part of a list, and doesn't
know that that list is being interpolated. However, maybe we should
allow interpolation of a bare @foo if is predeclared with a separator
(and maybe we could default to adding brackets the same way).
Likewise bare %foo could interpolate if predeclared with a method of
writing pairs and separators (and maybe brackets).
This is a little like the faulty Perl 4 rule of interpolating arrays
only if they'd been used, but in Perl 6 this would only be lexically
scoped, since the default would be attached to the array declaration,
and that would cause much less confusion than the Perl 4 rule.
Alternately, properties on the object itself could be used, but that
doesn't help us decide whether to interpolate bare @foo or %bar,
or whether to use separators or not.
: I can't figure to which object or class that property could belong, so maybe
: there should be just lexically scoped pragma...
Lexical declarations would most naturally attach to the variable
declaration in question, unless you want a pragma to affect all
subsequent syntax. But maybe it's just better to huffmanize the code
to specify the separator in line. We currently have
[EMAIL PROTECTED] ':'}
for that, but maybe we can shorten it further.
Larry
Re: String interpolation
On 2004-07-21 at 09:42:44, Larry Wall wrote:
Plus it ignores the fact that we've already introduced single character
scalar context operators that make it trivial to coerce from list
context to scalar. If {...} supplies list context by default, most
intepolations are either the same length or shorter:
$($foo) {$foo}
@(@foo) [EMAIL PROTECTED]
$(@foo) [EMAIL PROTECTED]
Memory failure here; the ~ forces string context, right? Could someone
please remind me how to spell binary not in Perl6?
Thanks.
-Mark
Re: String interpolation
--- Larry Wall [EMAIL PROTECTED] wrote:
If {...} supplies list context by default, most
intepolations are either the same length or shorter:
$($foo) {$foo}
@(@foo) [EMAIL PROTECTED]
$(@foo) [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Tres PHP, sir.
Plus, as I mentioned, it cleans up the $file.ext mess, the
[EMAIL PROTECTED] mess, and the %08x mess. That's three FAQs that
don't have to exist.
Ironically, I was grousing a couple of weeks back on the Sitepoint PHP
forum that the $foo vs. {$foo} interpolator wasn't smart enough -- it
had a limited submode for interpolated symbols instead of going into
'get me a var-exp'.
The flip side of that is that it's based on supporting two ways of
interpolating: plain $old text and special {$interpolated} text. I
wonder if you're talking about having just one {$interpolation} mode,
or if simple interpolations stay undelimited?
: The prospect of backslashing every opening brace in every
: interpolated string is not one I relish.
I'm just looking for what will be least confusing to the most
people here. We can certainly have other possible behaviors, but
something simple needs to be the default, and $() doesn't feel right
to me anymore.
Suppose there was a default that was you must quote curlies, and
alternates like:
q{ You must still quote curlies, else they interpolate. }
q( You must quote parens, else they interpolate. )
q[ You must quote brackets, else they interpolate. ]
(And, while I'm at it, how about the cool:
qv( sym )
which expands to the @(file, line) || $line on which SYM was
declared/first encountered. :-)
=Austin
Re: String interpolation
On Tue, Jul 20, 2004 at 08:35:10PM -0600, Luke Palmer wrote:
: This doesn't quite feel right to me. I was really a big fan of the good
: ol' Perl 6 days where you could interpolate as in Perl 5, and method
: calls required parentheses. I understand why Larry wanted to take out
: the parentheses, though... or rather why I'd want to take out the
: parentheses if I were him. It's so that people would stop thinking of
:
: $foo.bar
:
: as a method call, and more as an attribute. Or just more abstractly --
: less procedurally -- in general. This I'm all for.
:
: But then making them interpolate without parens get's a little to
: loose for my tastes. Perl's then come to the point of doing too much
: for me, and I want it to just sit down and shut up.
By analogy, we could add a row:
Interpolates
No Yes
-- ---
@foo@foo[1]
%bar%bar{a}
$foo.bar$foo.bar()
The basic rule of thumb seems to be shaping up that anything more
complicated than a simple scalar variable must always end with something
bracketed. (And in the case of closure {...}, that's the whole thing.)
Hmm. That makes me wonder what the slice notation for everything is.
Larry
Re: String interpolation
On Wed, Jul 21, 2004 at 01:13:29PM -0400, Mark J. Reed wrote:
: On 2004-07-21 at 09:42:44, Larry Wall wrote:
: Plus it ignores the fact that we've already introduced single character
: scalar context operators that make it trivial to coerce from list
: context to scalar. If {...} supplies list context by default, most
: intepolations are either the same length or shorter:
:
: $($foo) {$foo}
: @(@foo) [EMAIL PROTECTED]
: $(@foo) [EMAIL PROTECTED]
:
: Memory failure here; the ~ forces string context, right? Could someone
: please remind me how to spell binary not in Perl6?
The mnemonic is that it's like xoring with all ones, so it's C^,
except that the bitops are all demoted to needing a numerifying
C+ in front, so it comes out to C+^, unless you meant stringwise
binary not, in which case it's C~^. In either case, there is both
an infix operator for xoring two values, plus a unary operator that
xors with an assumed value of all ones. In any event, it's all very
regular now, with no dependencies on the prior history of the values
in question (unlike in Perl 5).
Larry
Re: String interpolation
Larry Wall wrote:
Hmm. That makes me wonder what the slice notation for everything is.
maybe @foo[..] (a short form for @foo[0..Inf]) ? %foo{..} should also be
allowed, of course (which
unfortunately is not a short form for 0..Inf). or perhaps, with a slight
analogy with filesystems, @foo[*]
and %foo{*}. I was tempted to suggest yada-yada-yada (eg. @foo[...]),
but this should mean a slice
not (yet) determined, right?
cheers,
Aldo
Re: String interpolation
On Tue, Jul 20, 2004 at 11:00:39PM -0700, chromatic wrote:
: On Tue, 2004-07-20 at 19:35, Luke Palmer wrote:
:
: The New Way (tm) to do that would probably be sticking a role onto the
: array object with which you're dealing:
:
: my @foo does separator('//') = (1,2,3,4,5);
: say [EMAIL PROTECTED]; # 1//2//3//4//5
:
: Shh, no one's let slip the idea of curried roles yet! I'm not even
: certain A12 mentioned parametric roles, let alone first-class roles.
Well, A12 did talk about parametric roles, but I glossed over the
first-class roles a bit. I didn't want to scare people with
$foo does $bar
though, of course, there's no reason in principle you shouldn't be able
to do that as a run-time operation. You just can't instantiate a role
object. The murky area in the middle is, of course, how you specify
an initial value aimed at the attributes of a particular role without
creating a real object containing just those values. Passing around
lists of pairs is probably good enough for that, as long as you can
keep straight which list of pairs is intended to initialize which
roles.
Larry
Re: String interpolation
On Wed, Jul 21, 2004 at 07:35:08PM +0200, Aldo Calpini wrote:
Larry Wall wrote:
Hmm. That makes me wonder what the slice notation for everything is.
maybe @foo[..] (a short form for @foo[0..Inf]) ?
Surely you mean [EMAIL PROTECTED] instead of 0..Inf
%foo{..} should also be allowed, of course (which unfortunately is not
a short form for ..Inf).
The long way is %foo{%foo.keys} and @[EMAIL PROTECTED] Maybe we
could use %foo{%} and @[EMAIL PROTECTED] Nah, I still like .. as the
everything iterator: @foo[..] %foo{..}
or perhaps, with a slight analogy with filesystems, @foo[*]
and %foo{*}.
Doesn't feel right at all.
-Scott
--
Jonathan Scott Duff Division of Nearshore Research
[EMAIL PROTECTED] Senior Systems Analyst II
Re: String interpolation
On Wed, Jul 21, 2004 at 07:35:08PM +0200, Aldo Calpini wrote:
: Larry Wall wrote:
:
: Hmm. That makes me wonder what the slice notation for everything is.
:
:
: maybe @foo[..] (a short form for @foo[0..Inf]) ? %foo{..} should also be
: allowed, of course (which
: unfortunately is not a short form for 0..Inf). or perhaps, with a slight
: analogy with filesystems, @foo[*]
: and %foo{*}. I was tempted to suggest yada-yada-yada (eg. @foo[...]),
: but this should mean a slice
: not (yet) determined, right?
That's correct.
I suspect the star is likely for everything, since whatever we choose
has to work not just as @foo[*] but also in individual dimensions:
@foo[1;*;0].
We do have to figure out whether C* as a term is too ambiguous with
C* as a unary splat. On the plus side, everything is a rather
splatty concept already. And it reads a lot better that C.. does.
Larry
Re: String interpolation
Brent 'Dax' Royal-Gordon writes:
Luke Palmer wrote:
I admit there's a certain interest to Larry's new idea. I've been
looking for more distinction between $, @, and % in Perl 6, since they
start to become mostly irrelavent. In the new proposal:
my @a = (1,2,3,4,5);
my $a = @a;
say @a; # @a
say $a; # 1 2 3 4 5 (perhaps?)
I think that's a bad kind of distinction, personally. It breaks an
obvious parallel.
But I'll admit that I'm much more a fan of $() and @() than I am of {}.
Form.pm would get very angry at this decision indeed.
Amen. Please don't steal unnecessary metacharacters in qq()
strings--although I still think we should keep it, @ causes a lot of
problems.
On the other hand, this is another step unifying strings and regexes. I
can say pretty confidently that that's a Good Thing.
The equivalent regex syntax isn't interpolating, even to the extent that
a bare $foo or @bar is, so this would be sort of a false cognate--IMHO
another reason not to have interpolating {}.
Yeah, I agree with you. I was stretching big time to find the merit in
the idea.
I suppose another good thing is that it makes unneccesary the balanced
brace rule in qq{} that was there in Perl 5: all braces need to be
backwhacked now. However, all braces need to be backwhacked now. Ugh.
I was dreading code-generating heredocs, but with the inclusion of
\qq[], that turns out not to be a problem:
my $code = eval 'CODE';
sub () {
my \qq[$name] = 0;
...
}
CODE
and what about @a[1]('arg')[3]?
That probably wouldn't.
Actually, I have to wonder why foo('bar', 'baz') wasn't on Larry's
list. Is there a reason for that?
Probably because foo('bar', 'baz') isn't a function call. All that
does is refer to a function foo with a siglet ('bar','baz'), which
means either nothing or a syntax error. The function call looks like
foo('bar', 'baz');
The New Way (tm) to do that would probably be sticking a role onto the
array object with which you're dealing:
my @foo does separator('//') = (1,2,3,4,5);
say [EMAIL PROTECTED]; # 1//2//3//4//5
I would think you'd use a property:
my @foo = (1,2,3,4,5) but separator('//');
[snip]
Roles are nice, but don't forget about the other mechanisms in Perl for
such things.
Erm, properties *are* roles. Your example is the same as mine.
I was thinking in terms of roles because a role would obviously be the
fellow to modify the stringify method of the array. Attributes work
too, but that all depends on how Array is designed.
Luke
Re: String interpolation
Jonathan Scott Duff writes: On Wed, Jul 21, 2004 at 07:35:08PM +0200, Aldo Calpini wrote: Larry Wall wrote: Hmm. That makes me wonder what the slice notation for everything is. maybe @foo[..] (a short form for @foo[0..Inf]) ? Surely you mean [EMAIL PROTECTED] instead of 0..Inf Same diff. The following are all identical @[EMAIL PROTECTED] @foo[0..Inf] @foo[0...] Unless you're assigning... in which case the latter two are probably more like what you want than the former. Luke
Re: String interpolation
On Wed, Jul 21, 2004 at 12:36:51PM -0600, Luke Palmer wrote:
: Brent 'Dax' Royal-Gordon writes:
: The equivalent regex syntax isn't interpolating, even to the extent that
: a bare $foo or @bar is, so this would be sort of a false cognate--IMHO
: another reason not to have interpolating {}.
:
: Yeah, I agree with you. I was stretching big time to find the merit in
: the idea.
Well, I don't think that's the important distinction. In each case
it's a closure that is evaluated at the appropriate point in time.
It's only the results of that closure that differ based on context,
and that's only to be expected. In terms of result, {...} is more
like /{...}/, I suppose.
: I suppose another good thing is that it makes unneccesary the balanced
: brace rule in qq{} that was there in Perl 5: all braces need to be
: backwhacked now. However, all braces need to be backwhacked now. Ugh.
Not really. Trailing braces need to be backwhacked only if the
initial ones are. Something to be said for symmetry...
: and what about @a[1]('arg')[3]?
:
: That probably wouldn't.
:
: Actually, I have to wonder why foo('bar', 'baz') wasn't on Larry's
: list. Is there a reason for that?
:
: Probably because foo('bar', 'baz') isn't a function call. All that
: does is refer to a function foo with a siglet ('bar','baz'), which
: means either nothing or a syntax error. The function call looks like
: foo('bar', 'baz');
Well, actually, lately foo('bar','baz') has mutated back into being
a function call, on the theory that Cfoo consistently produces a
reference and C.() consistently dereferences it. We only made the
non-call-rule of earlier because we wanted to have signatures like
foo(int,num)
but we later changed parametric type arguments to use square brackets,
and at the same time changed signatures to use
foo[int,num]
So now there's no ambiguity with letting foo(...) make a call.
Larry
Re: String interpolation
Luke Palmer wrote:
I suppose another good thing is that it makes unneccesary the balanced
brace rule in qq{} that was there in Perl 5: all braces need to be
backwhacked now. However, all braces need to be backwhacked now. Ugh.
I was dreading code-generating heredocs, but with the inclusion of
\qq[], that turns out not to be a problem:
my $code = eval 'CODE';
sub () {
my \qq[$name] = 0;
...
}
CODE
Didn't know that worked in single-quoted strings. Cute.
Actually, I have to wonder why foo('bar', 'baz') wasn't on Larry's
list. Is there a reason for that?
Probably because foo('bar', 'baz') isn't a function call. All that
does is refer to a function foo with a siglet ('bar','baz'), which
means either nothing or a syntax error. The function call looks like
foo('bar', 'baz');
Hmm...breaks the parallel with {} and []. But it seems to me that
foo.('bar','baz') should work, at least outside a string.
Roles are nice, but don't forget about the other mechanisms in Perl for
such things.
Erm, properties *are* roles. Your example is the same as mine.
True, I suppose...
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: String interpolation
On Tue, Jul 20, 2004 at 08:42:48PM -0400, Uri Guttman wrote:
: and how do you force scalar context without a scalar() or $() wrapper
: around the expression in {}? hard to say whether scalar or list context
: is more popular and so would get the huffman prize. i liked @() and $()
: for both context control and interpolation with context. it would do all
: the above but allow $($foo) instead of {$($foo)} and that saves 2 chars
: right there. maybe you could leave {} for list and have $() for scalar
: but that is inconsistant and bletcherous too.
Many expressions are naturally scalar even in list context. Most
operators force scalar context unless you hyper them. In particular,
the new unary operators C+, C~, and C? are specifically designed
to force scalar context in a huffmanly efficient way. Seems a little
silly to duplicate that with something longer.
: so whatever you do, make it symmetrical regarding context. even in perl5
: the @{[]} and ${\EXPR} tricks are both list context which is annoying
: (not that i use those tricks. i want the p6 style i mention above).
If you want symmetry you can always use a redundant C* in C[EMAIL PROTECTED]
to go with the redundant C~ in C{~$bar}.
: LW Note that this not only fixes the Perl 6 % in sprintf issue, but
: LW also the Perl 5 @ in email address issue. It also generalizes the
: LW notion that curlies (almost) always indicate a closure everywhere.
: LW On the other hand, it undoes my stated A12 policy that $x.foo can be
: LW used anywhere $foo can. On the gripping hand, it enables {.foo}
: LW where we would have had a lot of $_.foo, and I think that's an
: LW improvement in readability, at least for people who believe in topics.
:
: so does @() as that is not possible in an email address AFAIK. and that
: isn't a closure IMO as it is just an expression with no possibility for
: arguments (unless you come up with a way for that! :).
No, that only helps if you train everyone to always say @(@foo).edu
rather than @foo.edu.
: i don't think $foo.bar should be a method call. it is too easy to
: accidentally write and i bet many will fall into that trap. also it may
: generate a very odd runtime (since it is not a method call with a
: signature or declaration, it can't (easily?) be checked at compile time)
: message that may be hard to actually tie back to the string in question.
: so i would say, make interpolating method calls a little harder because
: it won't be done as often as simpler stuff (huffman) and it should be
: marked off as something completely different than simple variable
: interpolation.
That's the direction we're heading.
: so method calls would need the $() or @() wrappers as do all expressions
: beyond simple scalar value lookup. that means $foo, @foo[0], $foo[0],
: %foo{'bar'} and $foo{'bar'} all interpolate and only their variants
: (longer index/key expressions) do as well.
I'm inclining more towards the only interpolate things that end with
brackets or parens rule. That would allow $foo.bar() to interpolate,
but not $foo.bar.
: related question: given a ref to a scalar like $foo = \$bar, what is
: interpolated in these?
:
: $foo # similar to ref interpolation in p5?
: $($foo) # similar to ref interpolation in p5 as this is
: # just the scalar context op
: # or does this do a dereference as p5 would do?
: ${$foo) # deref and interpolate that value
Unlike in Perl 5, Perl 6's references will (by default) autodereference
to their representation in string context. (Not to be confused with
scalar context, where they remain references.) You have to do something
explicit to get the SCALAR(0xdeadbeef) form of output. I don't know what
that syntax is yet.
I probably shouldn't be thinking about that anyway. Can you all tell
I'm putting off writing my OSCON talk? :-)
Larry
Re: String interpolation
On Wed, Jul 21, 2004 at 12:39:57PM -0600, Luke Palmer wrote: Jonathan Scott Duff writes: On Wed, Jul 21, 2004 at 07:35:08PM +0200, Aldo Calpini wrote: Larry Wall wrote: Hmm. That makes me wonder what the slice notation for everything is. maybe @foo[..] (a short form for @foo[0..Inf]) ? Surely you mean [EMAIL PROTECTED] instead of 0..Inf Same diff. The following are all identical @[EMAIL PROTECTED] @foo[0..Inf] @foo[0...] Unless you're assigning... in which case the latter two are probably more like what you want than the former. Somehow I doubt that. If I'm in a loop that continually adds to an array and I want snapshots of how the array looks at particular points, I don't think that 0..Inf will do it. Maybe it will. Is Inf a magic token that really means something like look at your surrounding context and return the index of the last element of the structure you're iterating over? Because, pragmata aside, I'd expect 0..Inf to iterate forever (lazily, but still forever) including past the end of my arrays. -Scott -- Jonathan Scott Duff Division of Nearshore Research [EMAIL PROTECTED] Senior Systems Analyst II
Re: String interpolation
On Wed, 21 Jul 2004 10:21:58 -0700 (PDT), Austin Hastings
[EMAIL PROTECTED] wrote:
--- Larry Wall [EMAIL PROTECTED] wrote:
If {...} supplies list context by default, most
intepolations are either the same length or shorter:
$($foo) {$foo}
@(@foo) [EMAIL PROTECTED]
$(@foo) [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Tres PHP, sir.
hm.. and what if all the program inside quotes?..
step by step,
I've just tested that in perl5, just to improve my built-in head perl5
parser:
my $d=a;
print [EMAIL PROTECTED] $d='b']}--$d--\n;
print $d\n
__END__
--a--b--a--
a
funny.
that means it's equivalent to:
my $d=a;
print -- . $d . -- . join( $, do { my $d='b' } ) . -- . $d . --;
...
with all the scoping behavior. hm, now it's slightly clearer to me.
I used $d='b' ,and not $d=b above, just because it should be $d=\b\
yes, I know, perl5 parser makes several passes on quotes, and when it sees
open quote, it finds closing quote first, then parses all inside.
AFAIK, perl6 will be one-passing (with backtracking), and with new rules
it should be much easier to make a parsing recursion.. do we need in
this \ ?. why not to parse strings as rules? so here's the
Question:
perl6, Larry's new syntax:
my $d=a;
print --$d--{my $d = b }--$d--\n;
^ ^
is it correct?
if answer is yes, I can imagine one of the (not the best) styles of
perl6 CGI programming:
#!/usr/bin/perl6
use All::You::Need;
print END
Content-type: text/html
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0//EN
htmlhead title{...}{ #not decided yet
} /title
/head
body
{ my $res;
... #initialization
if $condition {
...;
$ret = qq{
psome html code here/p
oh my!... look here: {
{ my @res;
for CGI.param {
... # some sophisticated code
}
@res # of course we could (and should) use just
# Cmap or Cgrep here
}
don't you feel horror as me? it's a emhtml/em again!
}
}
else {
$ret = another piece of strangeness
}
$ret
}
html once again
/body
/html
END
__END__
looks somewhat similar to PHP.
is it readable?.. hm.. not less than {} inside rules, I think.. (I'm not
speaking about beauty now)
and if Cret for returning results from bare blocks (do, map, grep, and
such) would be in core, it could be even more (slightly) better.
IMHO, for user-level programmer, difference between {} and /{}/ isn't
very big. Yes, first is executed when it interpolated, second only
declares and executed only when called, but /.../ in void context is
called immediatelly.
( hm.. to push parallelism further, what about reference to interpolator..
hehe, think of lazy interpolation... *grin... nevermind..)
Oh my.. if my guessing about one-pass compilation of quoting constructs
was correct, does it mean that heredoc inside heredoc is possible?! :)
wow!. it's possible in perl5 too:
print FIRST;
1
2
@{[SECOND]}
3
4
SECOND
5
FIRST
__END__
1
2
3
4
5
Re: String interpolation
Larry Wall skribis 2004-07-21 10:24 (-0700):
Interpolates
NoYes
-----
@foo @foo[1]
%bar %bar{a}
$foo.bar $foo.bar()
Oh, please don't do that.
Whatever interpolation thing is invented, make it SIMPLE. Allowing
@foo[1], but not @foo is not simple.
In fact, with {}, is anything more than $foo and {} needed? Is $foo
needed, even (I'd like to have it, because I dislike brackets
everywhere)?
Juerd
Re: String interpolation
On Thu, Jul 22, 2004 at 12:31:08AM +0400, Alexey Trofimenko wrote:
: I used $d='b' ,and not $d=b above, just because it should be $d=\b\
: yes, I know, perl5 parser makes several passes on quotes, and when it sees
: open quote, it finds closing quote first, then parses all inside.
: AFAIK, perl6 will be one-passing (with backtracking), and with new rules
: it should be much easier to make a parsing recursion.. do we need in
: this \ ?. why not to parse strings as rules? so here's the
:
: Question:
:
: perl6, Larry's new syntax:
:
: my $d=a;
: print --$d--{my $d = b }--$d--\n;
:^ ^
: is it correct?
Yes, that is correct.
: Oh my.. if my guessing about one-pass compilation of quoting constructs
: was correct, does it mean that heredoc inside heredoc is possible?! :)
Ought to work unless we botch it somehow. The trick to parsing
heredocs correctly is that you have to store away the rest of the
current line somewhere safe, then parse the next lines as string with a
user-specified terminator. After completing the parse and finding that
terminator, you then go back to parsing the rest of the original line.
(Which may itself have another heredoc in it!)
Keeping the line numbers straight for error messages is also a bit
tricksy, but doable. Two-dimensional parsing is fun...
Larry
Re: String interpolation
On Wed, Jul 21, 2004 at 11:06:55PM +0200, Juerd wrote:
: Larry Wall skribis 2004-07-21 10:24 (-0700):
: Interpolates
: NoYes
: -----
: @foo @foo[1]
: %bar %bar{a}
: $foo.bar $foo.bar()
:
: Oh, please don't do that.
:
: Whatever interpolation thing is invented, make it SIMPLE. Allowing
: @foo[1], but not @foo is not simple.
It's simple in a different dimension, as the chart shows.
: In fact, with {}, is anything more than $foo and {} needed? Is $foo
: needed, even (I'd like to have it, because I dislike brackets
: everywhere)?
In theory we could require {} even on {$foo}. But we will certainly
allow bare $foo just because you asked for it. :-)
The rest is negotiable. I think we'll have riots if we don't at least
allow @foo[1] and %bar{a}. We've never allowed %foo by itself.
We allowed/required @foo to interpolate in Perl 5, and it catches a
certain number of people off guard regularly, including yours truly.
So I can argue [EMAIL PROTECTED] both ways.
We've never allowed methods or sub calls. We obviously can't
interpolate sigil-less foo(). We've flip-flopped about $foo.bar,
because it's definitely problematic either way. I still like my chart.
We could add another line to it that fits the same pattern:
No Yes
-- ---
@foo@foo[1]
%bar%bar{a} or %bar«a»
$foo.bar$foo.bar()
foofoo(1)
In this worldview, $foo is an exception only because it doesn't naturally
have a form that ends with some kind of bracket.
Larry
Re: String interpolation
LW == Larry Wall [EMAIL PROTECTED] writes:
LW On Tue, Jul 20, 2004 at 08:42:48PM -0400, Uri Guttman wrote:
LW Many expressions are naturally scalar even in list context. Most
LW operators force scalar context unless you hyper them. In particular,
LW the new unary operators C+, C~, and C? are specifically designed
LW to force scalar context in a huffmanly efficient way. Seems a little
LW silly to duplicate that with something longer.
someone mailed me off list about those. but you have to decide on
number/string/boolean context when you arelady have string context
surrounding it. seems like context overkill. what i liked about $() was
it just provided scalar context and the string context was provided by
.
LW If you want symmetry you can always use a redundant C* in C[EMAIL PROTECTED]
LW to go with the redundant C~ in C{~$bar}.
that is frumious IMO.
LW : i don't think $foo.bar should be a method call. it is too easy to
LW : accidentally write and i bet many will fall into that trap. also it may
LW : generate a very odd runtime (since it is not a method call with a
LW : signature or declaration, it can't (easily?) be checked at compile time)
LW : message that may be hard to actually tie back to the string in question.
LW : so i would say, make interpolating method calls a little harder because
LW : it won't be done as often as simpler stuff (huffman) and it should be
LW : marked off as something completely different than simple variable
LW : interpolation.
LW That's the direction we're heading.
same direction, different lane on the highway :)
LW : so method calls would need the $() or @() wrappers as do all expressions
LW : beyond simple scalar value lookup. that means $foo, @foo[0], $foo[0],
LW : %foo{'bar'} and $foo{'bar'} all interpolate and only their variants
LW : (longer index/key expressions) do as well.
LW I'm inclining more towards the only interpolate things that end with
LW brackets or parens rule. That would allow $foo.bar() to interpolate,
LW but not $foo.bar.
and i assume $foo is still fine even though it doesn't end in a bracket?
and also i assume you mean any of }, ] or )?
how would you put in the literal string $foo.bar()? escaping the . or
the ( ?
LW Unlike in Perl 5, Perl 6's references will (by default) autodereference
LW to their representation in string context. (Not to be confused with
LW scalar context, where they remain references.) You have to do something
LW explicit to get the SCALAR(0xdeadbeef) form of output. I don't know what
LW that syntax is yet.
that can be some longer func name as it is rarely needed IMO. mostly
debugging and some odd places that in p5 used it for a unique key or
class name.
LW I probably shouldn't be thinking about that anyway. Can you all tell
LW I'm putting off writing my OSCON talk? :-)
you too?! i would have never take you for a procrastinator! :)
i just wrote my main draft of my slides the other day.
why put off something today when you can put it off tomorrow?
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: String interpolation
Uri Guttman wrote: how would you put in the literal string $foo.bar()? escaping the . or the ( ? The dollar sign. (Or, if you wanted to interpolate $foo while leaving the .bar() intact, I would imagine that either \. or \( would suffice.) -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: String interpolation
Uri Guttman writes:
LW : so method calls would need the $() or @() wrappers as do all expressions
LW : beyond simple scalar value lookup. that means $foo, @foo[0], $foo[0],
LW : %foo{'bar'} and $foo{'bar'} all interpolate and only their variants
LW : (longer index/key expressions) do as well.
LW I'm inclining more towards the only interpolate things that end with
LW brackets or parens rule. That would allow $foo.bar() to interpolate,
LW but not $foo.bar.
and i assume $foo is still fine even though it doesn't end in a bracket?
and also i assume you mean any of }, ] or )?
how would you put in the literal string $foo.bar()? escaping the . or
the ( ?
Probably the $.
LW Unlike in Perl 5, Perl 6's references will (by default) autodereference
LW to their representation in string context. (Not to be confused with
LW scalar context, where they remain references.) You have to do something
LW explicit to get the SCALAR(0xdeadbeef) form of output. I don't know what
LW that syntax is yet.
that can be some longer func name as it is rarely needed IMO. mostly
debugging and some odd places that in p5 used it for a unique key or
class name.
Yeah, I use that unique key all the time. Perhaps that's what .id looks
like? I'd actually like it to be a short method name.
LW I probably shouldn't be thinking about that anyway. Can you all tell
LW I'm putting off writing my OSCON talk? :-)
you too?! i would have never take you for a procrastinator! :)
i just wrote my main draft of my slides the other day.
Haha, I'm procrastinating it as we speak. (But I'm calling it taking a
break).
why put off something today when you can put it off tomorrow?
Reminds me of Ellen Degenerous: Procrastinate now! Don't put it off!
Luke
Re: String interpolation
Two points, if I may jump in here:
(1) If the interpolation rule is to be simple as suggested, why not
impose this rule:
A character (except for a backslash) is interpreted literally if it
is not preceeded by a backslash.
For example,
The value is \$foo.bar(). -- The value is 3.
The value is $foo.bar(). -- 'The value is $foo.bar().'
The value is \{1+2}. -- The value is 3.
The value is {1+2}. -- The value is {1+2}.
[EMAIL PROTECTED] -- '[EMAIL PROTECTED]'
[EMAIL PROTECTED] -- '[EMAIL PROTECTED]'
$19.95 -- '19.95'
\$x -- '3'
%08x-- '%08x'
\%y -- '1 2 3 4' (or something)
(2) It seems that qq// and {} are on equal footing and should be
treated orthogonally. So, you could nest {} into qq// as such:
qq( The value is {1+1}. )
or vice-versa:
{ $x = qq(The value is) . (1+1) }
or nest each into itself, such as quotes inside quotes, such as
(something like) this:
qq(
style
div \{ color : { $yes ? 'blue' : 'white' } \}
/style
q[ Just $19.95! ]
)
so as not to require another level of {}:
qq( ... { q[ Just $19.95! ] })
Further, {} should be able to use any bracket type, just as qq// can
take the forms qq(), qq{}, qq, etc. Something like this:
qq(
style
div { color : e[ $yes ? 'blue' : 'white' ] }
/style
e '{' x 4
q[ Just $19.95! ]
e '}' x 4
)
Under my first proposal, this is rewritten unambiguously as
qq(
style
div { color : \e[ $yes ? 'blue' : 'white' ] }
/style
\e '{' x 4
Just $19.95!
\e '}' x 4
)
-davidm
Larry Wall wrote:
On Tue, Jul 20, 2004 at 09:20:56PM -0400, Damian Conway wrote:
: So what about:
:
: $foo[$i]
: $foo{$k}
:
: ???
Those would work.
: And would slices interpolate?
Yes. Slices are entirely determined by what's in the subscript.
: I can't say I'm keen on making {...} special in strings.
It had to grow on me a while too.
: I felt that the $(...) and @(...) were a much cleaner and more
: general solution.
Yeah, I felt that way too. But then I start looking at teaching people
the subtle difference between
${} $()
@{} @()
%{} %() ?
{} () ???
and realize that this is the only holdover from Perl 5 where we use
the sigil to indicate the internal context rather than the type of
the object expected. It's a danger sign that we have to keep repeating
ourselves (or not, as the case may be):
$($foo)
@(@foo)
$(@foo)
Plus it ignores the fact that we've already introduced single character
scalar context operators that make it trivial to coerce from list
context to scalar. If {...} supplies list context by default, most
intepolations are either the same length or shorter:
$($foo) {$foo}
@(@foo) [EMAIL PROTECTED]
$(@foo) [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
It also encourages people be more specific about *which* scalar
context they're looking for. It fits in with the general trend in Perl 6
that the default context is list context if you don't know better.
Plus, as I mentioned, it cleans up the $file.ext mess, the
[EMAIL PROTECTED] mess, and the %08x mess. That's three FAQs that
don't have to exist.
: The prospect of backslashing every opening brace in every interpolated string
: is not one I relish.
I'm just looking for what will be least confusing to the most
people here. We can certainly have other possible behaviors, but
something simple needs to be the default, and $() doesn't feel right
to me anymore.
Larry
Re: String interpolation
On Tue, Jul 20, 2004 at 06:28:11PM -0400, Aaron Sherman wrote:
: My preference is $file\.ext. Clear, light and ascii.
:
: That's fine as far as it goes, but how do you say what, in Perl 5, I
: would use this for:
:
: ${foo}n
:
: I like the ${} syntax, but I'm a shell guy from my early days... long
: before I touched Perl. If ${} is going to go away, then it seems like
: the best route is one of:
:
: * The pythonish %sn % ($foo) sprintf operator, something other
: than % though. Might even be - with appropriate layers of sugar
: * $($file)n
: * $file\bn \b is word-break in regexp, so it makes sense to me
: here mnemonically. Could even have $\b$money\bM is a lot which
: would force the lone $ to be literal in the same way as
: \$$money\bM is a lot would. Kinda fun.
Those are all pretty bletcherous.
Actually, I've been rethinking this whole mess since last week, and
am seriously considering cranking up the Ruby-o-meter here just a tad.
At the moment I'm inclined to say that the *only* interpolators in
double quotes are:
\n, \t etc.
$foo
@foo[$i]
%foo{$k}
{EXPR}
where the last provides a list context to EXPR. So all of these
would require curlies:
{foo()}
[EMAIL PROTECTED]
{%foo}
{$foo.bar}
{Dog.wag}
{.count}
{~localtime}
[EMAIL PROTECTED]
[EMAIL PROTECTED] '.'}
{$x.as %10.5d}
Note that this not only fixes the Perl 6 % in sprintf issue, but
also the Perl 5 @ in email address issue. It also generalizes the
notion that curlies (almost) always indicate a closure everywhere.
On the other hand, it undoes my stated A12 policy that $x.foo can be
used anywhere $foo can. On the gripping hand, it enables {.foo}
where we would have had a lot of $_.foo, and I think that's an
improvement in readability, at least for people who believe in topics.
Larry
Re: String interpolation
LW == Larry Wall [EMAIL PROTECTED] writes:
LW Actually, I've been rethinking this whole mess since last week, and
LW am seriously considering cranking up the Ruby-o-meter here just a tad.
LW At the moment I'm inclined to say that the *only* interpolators in
LW double quotes are:
LW \n, \t etc.
LW $foo
LW @foo[$i]
LW %foo{$k}
LW {EXPR}
LW where the last provides a list context to EXPR. So all of these
LW would require curlies:
LW {foo()}
LW [EMAIL PROTECTED]
LW {%foo}
LW {$foo.bar}
LW {Dog.wag}
LW {.count}
LW {~localtime}
LW [EMAIL PROTECTED]
LW [EMAIL PROTECTED] '.'}
LW {$x.as %10.5d}
and how do you force scalar context without a scalar() or $() wrapper
around the expression in {}? hard to say whether scalar or list context
is more popular and so would get the huffman prize. i liked @() and $()
for both context control and interpolation with context. it would do all
the above but allow $($foo) instead of {$($foo)} and that saves 2 chars
right there. maybe you could leave {} for list and have $() for scalar
but that is inconsistant and bletcherous too.
so whatever you do, make it symmetrical regarding context. even in perl5
the @{[]} and ${\EXPR} tricks are both list context which is annoying
(not that i use those tricks. i want the p6 style i mention above).
LW Note that this not only fixes the Perl 6 % in sprintf issue, but
LW also the Perl 5 @ in email address issue. It also generalizes the
LW notion that curlies (almost) always indicate a closure everywhere.
LW On the other hand, it undoes my stated A12 policy that $x.foo can be
LW used anywhere $foo can. On the gripping hand, it enables {.foo}
LW where we would have had a lot of $_.foo, and I think that's an
LW improvement in readability, at least for people who believe in topics.
so does @() as that is not possible in an email address AFAIK. and that
isn't a closure IMO as it is just an expression with no possibility for
arguments (unless you come up with a way for that! :).
i don't think $foo.bar should be a method call. it is too easy to
accidentally write and i bet many will fall into that trap. also it may
generate a very odd runtime (since it is not a method call with a
signature or declaration, it can't (easily?) be checked at compile time)
message that may be hard to actually tie back to the string in question.
so i would say, make interpolating method calls a little harder because
it won't be done as often as simpler stuff (huffman) and it should be
marked off as something completely different than simple variable
interpolation.
so method calls would need the $() or @() wrappers as do all expressions
beyond simple scalar value lookup. that means $foo, @foo[0], $foo[0],
%foo{'bar'} and $foo{'bar'} all interpolate and only their variants
(longer index/key expressions) do as well.
related question: given a ref to a scalar like $foo = \$bar, what is
interpolated in these?
$foo # similar to ref interpolation in p5?
$($foo) # similar to ref interpolation in p5 as this is
# just the scalar context op
# or does this do a dereference as p5 would do?
${$foo) # deref and interpolate that value
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: String interpolation
Larry wrote:
Actually, I've been rethinking this whole mess since last week, and
am seriously considering cranking up the Ruby-o-meter here just a tad.
At the moment I'm inclined to say that the *only* interpolators in
double quotes are:
\n, \t etc.
$foo
@foo[$i]
%foo{$k}
{EXPR}
where the last provides a list context to EXPR. So all of these
would require curlies:
{foo()}
[EMAIL PROTECTED]
{%foo}
{$foo.bar}
{Dog.wag}
{.count}
{~localtime}
[EMAIL PROTECTED]
[EMAIL PROTECTED] '.'}
{$x.as %10.5d}
So what about:
$foo[$i]
$foo{$k}
???
And would slices interpolate?
I can't say I'm keen on making {...} special in strings. I felt that the
$(...) and @(...) were a much cleaner and more general solution. The prospect
of backslashing every opening brace in every interpolated string is not one I
relish.
Damian
Re: String interpolation
On Tue, 20 Jul 2004 16:06:40 -0700, Larry Wall [EMAIL PROTECTED] wrote:
Actually, I've been rethinking this whole mess since last week, and
am seriously considering cranking up the Ruby-o-meter here just a tad.
At the moment I'm inclined to say that the *only* interpolators in
double quotes are:
\n, \t etc.
$foo
@foo[$i]
%foo{$k}
{EXPR}
where the last provides a list context to EXPR. So all of these
would require curlies:
{foo()}
[EMAIL PROTECTED]
{%foo}
{$foo.bar}
{Dog.wag}
{.count}
{~localtime}
[EMAIL PROTECTED]
[EMAIL PROTECTED] '.'}
{$x.as %10.5d}
Note that this not only fixes the Perl 6 % in sprintf issue, but
also the Perl 5 @ in email address issue. It also generalizes the
notion that curlies (almost) always indicate a closure everywhere.
On the other hand, it undoes my stated A12 policy that $x.foo can be
used anywhere $foo can. On the gripping hand, it enables {.foo}
where we would have had a lot of $_.foo, and I think that's an
improvement in readability, at least for people who believe in topics.
ah.. how poorly.. and how sufficient!.. But it's.. it's just not quite
like in perl5.. But I can adopt myself. :) I doubt about @arr disabling,
but {} interpolator is cool!
(hm.. looks like Perl6 will not require special HTML templating packages
in 90% cases.. qq[ tag attr={.property} ] would be enough for me almost
always)
some questions:
1) is @a[1][2]{'a'}b interpolateable? and what about @a[1]('arg')[3]?
2) what's the default separator for list interpolation?
{1,2,3} eq 123 or
{1,2,3} eq 1 2 3 ?
and is there any way to redefine it, as assigment to perl5 @ does? I
can't figure to which object or class that property could belong, so maybe
there should be just lexically scoped pragma...
Re: String interpolation
Alexey Trofimenko writes:
On Tue, 20 Jul 2004 16:06:40 -0700, Larry Wall [EMAIL PROTECTED] wrote:
So all of these would require curlies:
{foo()}
[EMAIL PROTECTED]
...
ah.. how poorly.. and how sufficient!.. But it's.. it's just not quite
like in perl5.. But I can adopt myself. :) I doubt about @arr disabling,
but {} interpolator is cool!
This doesn't quite feel right to me. I was really a big fan of the good
ol' Perl 6 days where you could interpolate as in Perl 5, and method
calls required parentheses. I understand why Larry wanted to take out
the parentheses, though... or rather why I'd want to take out the
parentheses if I were him. It's so that people would stop thinking of
$foo.bar
as a method call, and more as an attribute. Or just more abstractly --
less procedurally -- in general. This I'm all for.
But then making them interpolate without parens get's a little to
loose for my tastes. Perl's then come to the point of doing too much
for me, and I want it to just sit down and shut up.
I admit there's a certain interest to Larry's new idea. I've been
looking for more distinction between $, @, and % in Perl 6, since they
start to become mostly irrelavent. In the new proposal:
my @a = (1,2,3,4,5);
my $a = @a;
say @a; # @a
say $a; # 1 2 3 4 5 (perhaps?)
But I'll admit that I'm much more a fan of $() and @() than I am of {}.
Form.pm would get very angry at this decision indeed.
On the other hand, this is another step unifying strings and regexes. I
can say pretty confidently that that's a Good Thing.
On the mutant growth hand, it's just too weird. Come on, just be
conservative (or liberal, depending on whether you're talking culturally
or syntactically)! It was pretty good before. With $() and @(), it's
better than before.
(hm.. looks like Perl6 will not require special HTML templating packages
in 90% cases.. qq[ tag attr={.property} ] would be enough for me almost
always)
some questions:
1) is @a[1][2]{'a'}b interpolateable?
I should hope that Larry hasn't gone completely insane (or should I say
more insane ;-). That ought to work.
and what about @a[1]('arg')[3]?
That probably wouldn't.
2) what's the default separator for list interpolation?
{1,2,3} eq 123 or
{1,2,3} eq 1 2 3 ?
I definitely liked space as in Perl 5. It was the simplest thing that
you could pick: perfectly clear where the elements are.
and is there any way to redefine it, as assigment to perl5 @ does? I
can't figure to which object or class that property could belong, so maybe
there should be just lexically scoped pragma...
The New Way (tm) to do that would probably be sticking a role onto the
array object with which you're dealing:
my @foo does separator('//') = (1,2,3,4,5);
say [EMAIL PROTECTED]; # 1//2//3//4//5
Re: string interpolation
On Fri, Jan 25, 2002 at 05:07:48PM -0800, Dew-Jones, Malcolm MSER:EX wrote: Lets add an .interpolate method. The parameter(s) are rules that control the interpolation, and the returned value is the interpolated string using those rules. $result = 'scalar $vars (only) will be interpolated' . interpolate($) ; I'm actually just thinking about how to do interpolation now; I'm basically using Perl 5 rules for the most part. The thing that worries me about this idea of yours is that interpolate certainly looks like a method, but it isn't; the arguments you're passing in aren't real arguments at all, they're not ordinary Perl syntax. In fact, you've made up a special tiny domain-specific language for conveying how to interpolate certain things. Now, there's nothing wrong with tiny domain-specific languages, given the right domain. For instance, regular expressions are the right domain. But when you add a little DSL, you have to tell the parser to stop parsing ordinary Perl, and start parsing something else. And you want to do this when you see an interpolate method on a string. Or maybe not just on a string - maybe interpolate becomes a special method on everything, which takes this special syntax. Either way, I'm not sure this is something you want to be making up new syntax for. scenario two, same idea but using =~ notation. Slightly better, but =~ means match in some sense, and that sense is getting broader in Perl 6. And interpolation doesn't have very much in common with matching. -- It's a testament to the versatility of the human mind that we're so able to compensate for our own incompetence. - Darrell Furhiman
