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 or
© 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: This week's summary
Austin Hastings <[EMAIL PROTECTED]> writes: > --- The Perl 6 Summarizer <[EMAIL PROTECTED]> wrote: >> Okay, so the interview was on Tuesday 13th of July. >> It went well; I'm going to be a maths teacher. [...] > As we all know, time flies like an arrow, but fruit flies like a > banana. If you found this mathematical summary helpful, please consider > paying your tuition you ungrateful little bastards." ** Gurfle **
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 C 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 C<&foo> 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
{...}{ #not decided yet
}
{ my $res;
... #initialization
if $condition {
...;
$ret = qq{
some html code here
oh my!... look here: {
{ my @res;
for CGI.param {
... # some sophisticated code
}
@res # of course we could (and should) use just
# C or C here
}
don't you feel horror as me? it's a html again!
}
}
else {
$ret = "another piece of strangeness"
}
$ret
}
html once again
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 C 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()
&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.
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(
div \{ color : { $yes ? 'blue' : 'white' } \}
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(
div { color : e[ $yes ? 'blue' : 'white' ] }
e< '{' x 4 >
q[ Just $19.95! ]
e< '}' x 4 >
)
Under my first proposal, this is rewritten unambiguously as
qq(
div { color : \e[ $yes ? 'blue' : 'white' ] }
\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
Larry Wall skribis 2004-07-21 12:25 (-0700): > 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. Anything that is decided by something's end makes things hard to read, hard to learn and probably harder to parse. Why fix this with regexes and then reintroduce it in interpolation? Juerd
