Re: Selective String Interpolation
On 19/02/06 03:48, Jonathan Lang wrote:
I don't see why you'd need a universal anti-backwhack, any more than
you need universal quote delimiters.
Here-docs are usually safe to quote any amount of line noise,
but I take your point.
I could see introducing an
adverb to the quoting mechanism that lets you define a custom
backwhack character in qq strings (for those rare cases where literal
backslashes are common occurrences), and then press the same adverb
into service in q strings to define a custom anti-backwhack. The only
difference is that there's a default backwhack character (the
backslash), but there is no default anti-backwhack. So:
my $code = q:interp(`){
package `$package_name;
sub `$sub_name {
`$the_complex_value_we_want_to_use_in_generated_code
}
sub `$another_sub_name {
[EMAIL PROTECTED](';')}
}
};
This would scratch my itch. The interpolated bits are more visually
distinct than in my by-name proposal, which is a clear advantage.
(No pun intented)
I don't like the idea of sharing the adverb between escaping and
force-interpolating since stacking other adverbs can turn q into qq
and vice-versa. That's a minor quibble though.
I'd go so far as to say that the anti-backwhack would only have a
special meaning in front of a $, @, %, {, \, or another
anti-backwhack; in all other cases, it gets treated as a literal
character just like anything else. There may be some edge conditions
that I haven't thought of; but I think that this is a decent baseline
to work from.
In cases like q:c:interp(`) { ... }, then only `{...} would need a
special meaning.
The only disadvantage that has occured to me is the complexity
of adding yet another feature. Syntax highlighters and other
tools would have to handle it.
I think the Huffman encoding is correct on this, up to and including
the length of the adverb needed to define a custom backwhack or
anti-backwhack.
I agree. This can be kept in Perl 6's attic most of the time.
Alternatively, it can be a user-defined capability since S06 specifically
allows such tinkering. Whether to include the feature in basic Perl
depends on the utility-complexity trade off. I don't have a strong
preference either way, as long as it can be done somehow.
Analogous issues occur with quasiquoting, so a solution that can be
naturally shared would be ideal. CODE :interp(`) { say `$a + $b }
... hmm, looks ok...
Brad
--
After reading books and the like it is best to burn them or throw them away.
-- Hagakure http://bereft.net/hagakure/
Re: Selective String Interpolation
Brad Bowman wrote:
I don't like the idea of sharing the adverb between escaping and
force-interpolating since stacking other adverbs can turn q into qq
and vice-versa. That's a minor quibble though.
And a reasonable one as well. I was trying to minimize the
proliferation of adverbs, but I may have gone overboard by trying to
fit crucially different things under the same tent. Separate :esc and
:interp adverbs probably would be better overall.
Analogous issues occur with quasiquoting, so a solution that can be
naturally shared would be ideal. CODE :interp(`) { say `$a + $b }
... hmm, looks ok...
I'm not familiar with quasiquoting, so I wouldn't know. The interp
part seems fairly straightforward; if $a = 5 and $b = 4, I'd expect
the above to be equivalent to CODE { say 5 + $b }, whatever that
means.
--
Jonathan Dataweaver Lang
Re: Selective String Interpolation
Damian Conway [EMAIL PROTECTED] writes:
Brad Bowman asked:
When building code strings in Perl 5 I usually write the code,
then wrap it in double quotes, then \ escape everything light blue
under syntax highlighting. I was wondering if there'll a better
way in Perl 6. I thought it would be nice to define the variables
you wish to
interpolate individually, perhaps as extensions to the :s, :a,
etc quote adverbs, perhaps using a signature object.
There is already a mechanism for this. You simply turn off all
variable interpolation, and interpolate any the variables you wish to
interpolate via block interpolations. Or, more simply, only turn on
block interpolation in a non-interpolating string:
my $code = q:c{
package {$package_name};
sub {$sub_name} \{
return {$return_val}
\}
};
The problem here is that sometimes (especially in code generation) you
don't really want to interpolate the stringification of a value, you
just want the value itself. I've been struggling with this slightly
when I've been writing code generation methods in Ruby. Where, in
Scheme or lisp you'd simply use some combination of C`, C, and
C,@, in Ruby you end up having to store values somewhere in the
binding that will be accessed by your compiled code; which would be
fine if (again, as with Lisp macros) you could generate what I tend to
think of as an anonymous symbol to bind the value to:
my $anon_symbol = gensym
my ${$anon_symbol} = $the_complex_value_we_want_to_use_in_generated_code
my $code = q:c{
package {$package_name};
sub {$sub_name} \{
return ${$anon_symbol}
\}
};
And backwhacking braces in generated code is *not* a pretty solution
to my eyes. I'd *like* to be able to have a quasiquoting environment
along the lines of lisp's backquote (though I'm not sure about the
unquoting syntax):
my $code = q:`{
package ,$package_name;
sub ,$sub_name {
,$the_complex_value_we_want_to_use_in_generated_code
}
sub ,$another_sub_name {
,[EMAIL PROTECTED](';')}
}
};
Whatever we go with, we need a quoting mechanism that returns a parse
tree rather than a simple string if we want to deal with interpolating
complex values (especially if we don't want to have to worry about
what, if any, quotes are needed round some of our interpolated values.
--
Piers Cawley [EMAIL PROTECTED]
http://www.bofh.org.uk/
Re: Selective String Interpolation
Piers Cawley wrote: And backwhacking braces in generated code is *not* a pretty solution to my eyes. I'd *like* to be able to have a quasiquoting environment along the lines of lisp's backquote (though I'm not sure about the unquoting syntax): Let me see if I understand this correctly: Instead of interpolation being enabled by default with backwhacks selectively disabling it, you want something where interpolation is disabled by default with anti-backwhacks selectively enabling it. Right? -- Jonathan Dataweaver Lang
Re: Selective String Interpolation
On 18/02/06 07:49, Damian Conway wrote:
There is already a mechanism for this. You simply turn off all variable
interpolation, and interpolate any the variables you wish to interpolate
via block interpolations. Or, more simply, only turn on block
interpolation in a non-interpolating string:
my $code = q:c{
package {$package_name};
sub {$sub_name} \{
return {$return_val}
\}
};
The curlies then need escaping. I was seeking a way to avoid escaping
either every set of curlies or every non-interpolated varible (not shown
in your snippet). It's true that in some case adverb forms may be
useful in reducing backslashing. The :f form may be better in cases
where [EMAIL PROTECTED] are all common and is absent or rare.
sub v { return @_ };
my $code = q:f{
package v($package_name);
my $increment = 2;
sub v($sub_name) {
return v($return_val) + $increment;
}
};
If f{$package_name} is legal then that looks even nicer.
Brad
--
Singlemindedness is all powerful. -- Hagakure
Re: Selective String Interpolation
On 18/02/06 12:23, Jonathan Lang wrote: Piers Cawley wrote: And backwhacking braces in generated code is *not* a pretty solution to my eyes. I'd *like* to be able to have a quasiquoting environment along the lines of lisp's backquote (though I'm not sure about the unquoting syntax): Let me see if I understand this correctly: Instead of interpolation being enabled by default with backwhacks selectively disabling it, you want something where interpolation is disabled by default with anti-backwhacks selectively enabling it. Right? Not speaking for Piers... Something like that, although trying to find universal anti-backwhacks in the strings handled by Perl is much harder than finding meta-syntax for S-expressions. That's why I was suggesting a mechanism to selectively enable interpolation by name rather than syntax. There are a number of alternatives, from the :s,:c,:f adverbs to using something like Template Toolkit, so unless a neat solution can be found the cure is probably worse than the illness. Brad -- ... One should think well then speak. ... -- Hagakure
Re: Selective String Interpolation
Brad Bowman wrote:
Jonathan Lang wrote:
Let me see if I understand this correctly: Instead of interpolation
being enabled by default with backwhacks selectively disabling it, you
want something where interpolation is disabled by default with
anti-backwhacks selectively enabling it. Right?
Not speaking for Piers...
Something like that, although trying to find universal anti-backwhacks
in the strings handled by Perl is much harder than finding meta-syntax
for S-expressions. That's why I was suggesting a mechanism to selectively
enable interpolation by name rather than syntax.
I don't see why you'd need a universal anti-backwhack, any more than
you need universal quote delimiters. I could see introducing an
adverb to the quoting mechanism that lets you define a custom
backwhack character in qq strings (for those rare cases where literal
backslashes are common occurrences), and then press the same adverb
into service in q strings to define a custom anti-backwhack. The only
difference is that there's a default backwhack character (the
backslash), but there is no default anti-backwhack. So:
my $code = q:interp(`){
package `$package_name;
sub `$sub_name {
`$the_complex_value_we_want_to_use_in_generated_code
}
sub `$another_sub_name {
[EMAIL PROTECTED](';')}
}
};
I'd go so far as to say that the anti-backwhack would only have a
special meaning in front of a $, @, %, {, \, or another
anti-backwhack; in all other cases, it gets treated as a literal
character just like anything else. There may be some edge conditions
that I haven't thought of; but I think that this is a decent baseline
to work from.
I think the Huffman encoding is correct on this, up to and including
the length of the adverb needed to define a custom backwhack or
anti-backwhack.
--
Jonathan Dataweaver Lang
Selective String Interpolation
Hello,
When building code strings in Perl 5 I usually write the code,
then wrap it in double quotes, then \ escape everything light blue
under syntax highlighting. I was wondering if there'll a better
way in Perl 6.
I thought it would be nice to define the variables you wish to
interpolate individually, perhaps as extensions to the :s, :a,
etc quote adverbs, perhaps using a signature object.
Since user-defined quotes are possible it shouldn't be too hard
to add in any case, so I might just leave off the waffling there.
One more waffle:
Closure interpolation seems largely incompatible strings.
Interpolation restricted by variable doesn't help this anyway
so perhaps there's a more general solution covering all cases.
(or just q:c(0))
Another possibility is that code string suppport may be less
important given the macro and grammar tools available.
On the other hand, the code is not always being generated for
immediate consumption and is not always Perl.
That probably counts as at least two waffles,
Brad
...Maybe CODE's dwimmy binding could be abused: (CODE { ... }).perl
--
The occurrence of mysteries is alway by word of mouth. -- Hagakure
Re: Selective String Interpolation
Brad Bowman asked:
When building code strings in Perl 5 I usually write the code,
then wrap it in double quotes, then \ escape everything light blue
under syntax highlighting. I was wondering if there'll a better
way in Perl 6.
I thought it would be nice to define the variables you wish to
interpolate individually, perhaps as extensions to the :s, :a,
etc quote adverbs, perhaps using a signature object.
There is already a mechanism for this. You simply turn off all variable
interpolation, and interpolate any the variables you wish to interpolate via
block interpolations. Or, more simply, only turn on block interpolation in a
non-interpolating string:
my $code = q:c{
package {$package_name};
sub {$sub_name} \{
return {$return_val}
\}
};
Damian
Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]
Larry Wall wrote: On Thu, Mar 31, 2005 at 03:03:09PM +0200, Thomas Sandlaß wrote: : BTW, will bidirectionality be supported? Does it make sense to reflect : it in the StrPos type such that $pos_start $pos_end means a non-empty : left to right string, $pos_start $pos_end is a non-empty right to left : string and $pos_start == $pos_end delimit an empty (sub)string? As a : natural consequence the sign indicates direction with negative length : beeing right to left. And that leads to two times two types of iterators: : left to right, right to left, start to end and end to start. Offhand I'd rather have end start be undefined, I think, but I suppose we could give it a meaning if it turns out not to be an easily generated degenerate case like 0..-1. On the other hand, I think right-to-left might deserve more Huffman visibility than an itty-bitty sign that might be hidden down in a varible. But then, we've played games with signs in substr and splice before. It's not clear that people would want substr($x, -3) to return the characters in reversed order, though. I don't see how rtl vs ltr changes how we process strings. It's purely a display problem. I seriously doubt the someone working with a rtl language would ever wish to count the characters ltr. And note that we are calling the positions start and end, not left and right. If I'm missing something basic here, let me know. -- Rod Adams
Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]
On Thu, Mar 31, 2005 at 03:03:09PM +0200, Thomas Sandlaß wrote:
: Larry Wall wrote:
: On Sat, Mar 26, 2005 at 02:37:24PM -0600, Rod Adams wrote:
: : How can you have a level independent position?
:
: By not confusing positions with numbers. They're just pointers into
: a particular string.
:
: I'm not the Unicode guru but my understanding is that all composition
: sequences are finite and stateless with respect to everything before
: and after them in the string. Which brings me to the question if these
: positions are defined like positions in Emacs as lying *between* the
: chars? Then the set of positions of a higher level is a subset of the
: positions of lower levels.
Yes, that's how I've been thinking of them. Thanks for making that explicit.
: With defining position as between chars many operations on strings are
: downwards compatible between levels, e.g. splitting. If one determines
: e.g. an insert position on a higher level there's no problem in letting
: the actual insertion beeing handled by a lower level. With fractional
: positions on higher levels some degree of upward or tunneling
: compatibility can be achieved.
That's my feeling.
: BTW, will bidirectionality be supported? Does it make sense to reflect
: it in the StrPos type such that $pos_start $pos_end means a non-empty
: left to right string, $pos_start $pos_end is a non-empty right to left
: string and $pos_start == $pos_end delimit an empty (sub)string? As a
: natural consequence the sign indicates direction with negative length
: beeing right to left. And that leads to two times two types of iterators:
: left to right, right to left, start to end and end to start.
Offhand I'd rather have end start be undefined, I think, but I
suppose we could give it a meaning if it turns out not to be an
easily generated degenerate case like 0..-1. On the other hand,
I think right-to-left might deserve more Huffman visibility than an
itty-bitty sign that might be hidden down in a varible.
But then, we've played games with signs in substr and splice before.
It's not clear that people would want substr($x, -3) to return the
characters in reversed order, though.
: All the above leads me to rant about an array like type. Please forgive
: me if the following is not proper Perl6. My point is to illustrate how
: I imagine the future communication between implementor and user of such
: a class. Actually some POD support for extracting the type information
: into the documentation would be great, too!
:
: And yes, the :analyse should be made lazy. The distinction between the
: first and second index method could be even more specific by using
: type 'Index ^ List of Str where { $_.elems == 1 }' to convey the
: information that indexing with a list of one element doesn't result
: in a List of Str but a plain Str. OTOH this will incur a performance
: penalty and violate the intuitive notion list in, list out.
MEGO.
: class StrPosArray does Array where { ::Index does StrPos }
: {
:has Str$:data;
:has StrPos @:pos;
:
:multi method postcircumfix:[ ]
:(: Index $i ) returns Str {...}
:multi method postcircumfix:[ ]
:(: List of Index $i ) returns List of Str {...}
:multi method postcircumfix:[ ]
:(: Range of Index $i ) returns List of Str {...}
:multi method postcircumfix:[ ]
:(:Int $i ) returns Str {...}
:
:# more stuff here for push, pop, shift etc.
:
:method infix:= (: Str $rhs ) returns ::?CLASS
:{
: $:data = $rhs;
: :analyse;
:}
:
:method :analyse ()
:{
: # scan $:data for all between char positions
: # and store them into @:pos
:}
: }
:
: Question:
: does the compiler go over this source in multiple passes
: such that the declaration of :analyse is known before its
: usage in infix:=?
No, you just throw in a forward declaration with {...} in that case.
Larry
Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]
Larry Wall wrote:
On Sat, Mar 26, 2005 at 02:37:24PM -0600, Rod Adams wrote:
: How can you have a level independent position?
By not confusing positions with numbers. They're just pointers into
a particular string.
I'm not the Unicode guru but my understanding is that all composition
sequences are finite and stateless with respect to everything before
and after them in the string. Which brings me to the question if these
positions are defined like positions in Emacs as lying *between* the
chars? Then the set of positions of a higher level is a subset of the
positions of lower levels.
With defining position as between chars many operations on strings are
downwards compatible between levels, e.g. splitting. If one determines
e.g. an insert position on a higher level there's no problem in letting
the actual insertion beeing handled by a lower level. With fractional
positions on higher levels some degree of upward or tunneling
compatibility can be achieved.
BTW, will bidirectionality be supported? Does it make sense to reflect
it in the StrPos type such that $pos_start $pos_end means a non-empty
left to right string, $pos_start $pos_end is a non-empty right to left
string and $pos_start == $pos_end delimit an empty (sub)string? As a
natural consequence the sign indicates direction with negative length
beeing right to left. And that leads to two times two types of iterators:
left to right, right to left, start to end and end to start.
All the above leads me to rant about an array like type. Please forgive
me if the following is not proper Perl6. My point is to illustrate how
I imagine the future communication between implementor and user of such
a class. Actually some POD support for extracting the type information
into the documentation would be great, too!
And yes, the :analyse should be made lazy. The distinction between the
first and second index method could be even more specific by using
type 'Index ^ List of Str where { $_.elems == 1 }' to convey the
information that indexing with a list of one element doesn't result
in a List of Str but a plain Str. OTOH this will incur a performance
penalty and violate the intuitive notion list in, list out.
class StrPosArray does Array where { ::Index does StrPos }
{
has Str$:data;
has StrPos @:pos;
multi method postcircumfix:[ ]
(: Index $i ) returns Str {...}
multi method postcircumfix:[ ]
(: List of Index $i ) returns List of Str {...}
multi method postcircumfix:[ ]
(: Range of Index $i ) returns List of Str {...}
multi method postcircumfix:[ ]
(:Int $i ) returns Str {...}
# more stuff here for push, pop, shift etc.
method infix:= (: Str $rhs ) returns ::?CLASS
{
$:data = $rhs;
:analyse;
}
method :analyse ()
{
# scan $:data for all between char positions
# and store them into @:pos
}
}
Question:
does the compiler go over this source in multiple passes
such that the declaration of :analyse is known before its
usage in infix:=?
--
TSa (Thomas Sandlaß)
Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]
Larry Wall wrote: On Sat, Mar 26, 2005 at 02:37:24PM -0600, Rod Adams wrote: : Please convince me your view works in practice. I'm not seeing it work : well when I attempt to define the relevent parts of S29. But I might : just be dense on this. Well, let's work through an example. multi method substr(Str $s: Ptr $start, PtrDiff ?$len, Str ?$repl) Depending on the typology of Ptr and PtrDiff, we can either coerce various dimensionalities into an appropriate Ptr and PtrDiff type within those classes, or we could rely on MMD to dispatch to a suite of substr implementations with more explicit classes. Interestingly, since Ptrs aren't integers, we might also allow multi method substr(Str $s: Ptr $start, Ptr ?$end, Str ?$repl) which might be a more natural way to deal with variable length encodings, and we just leave the lengthy version in there for old times sake. ...snip... for the non-destructive slicing of a string, and leave substr() with Perl 5 semantics, in which case it's just a SMOP to coerce the user's substr($a, 5, 10); to something the effectively means substr($a, Ptr.new($a, 5, $?UNI_LEVEL), PtrDiff.new(10, $?UNI_LEVEL)); Actually, in this case, I expect we're actually calling into multi method substr(Str $s: PtrDiff $start, PtrDiff ?$len, Str ?$repl) where $start will be counted from the begining of the string, so the call is effectively substr($a, PtrDiff.new(5, $?UNI_LEVEL), PtrDiff.new(10, $?UNI_LEVEL)); Okay, that looks scary, but if as in my previous message we define chars as the highest Unicode level allowed by the context and the string, then we can just write that in some notation resembling: substr($a, 5`Chars, 10`Chars); or whatever notation we end up with for labeling units on numbers. Even if we don't define chars that way, they just end up labeled with the current level (here assuming Codes): substr($a, 5`Codes, 10`Codes); or whatever. But this is all implicit, which is why you can just write substr($a, 5, 10); and have it DWYM. I see some danger here. In particular, there is a huge difference between a Ptr (position), and a PtrDiff (length). I'm going to rename these classes StrPos and StrLen for the time being. A StrPos can have multiple char units associated with it, and has the ability morph between them. However, it is also strictly bound to a given string. A StrLen can only have one char unit associated with it, since there is no binding string and anchors with which to reliably map how many cpts there are to so many lchars. I see the following operations being possible at a logical level: StrPos = StrPos + StrLen StrLen = StrPos - StrPos # must specify units (else implied), and must be same base Str StrLen = StrLen + StrLen # if same units. StrLen = StrLen + Int So I see the following cases of Substr happening: multi sub substr(Str $s, StrPos $start : StrPos ?$end, ?$replace) Where $start and $end must be anchored to $s multi sub substr(Str $s, StrPos $start, StrLen $length : ?$replace) Same restriction on $start, multi sub substr(Str $s, StrLen $offset : StrLen ?$length, ?$replace) Where $offset gets used as C$s.start + $offset and kicked over to case #2. Hmm. Okay, that's not dangerous, just a lot to look at. What gets dangerous is letting users think of a StrPos as a number, since it's not. Only StrLen's get to pretend to be numbers. StrPos should have some nifty methods to return StrLen's relative to it's base Str's .start, and those StrLens can look like a number, but the StrPos never gets to ever look like a number. Make it where StrLen does Int, and there's a C«coerce:as(Int,StrLen)» with default units of your Chars as highest supported by string applied to, and I think we're getting somewhere. We need to define what happens to a StrPos when it's base Str goes away. Having it assume some nifty flavor of undef would do the trick. This implies that a Str knows all the StrPos's hanging off it, so the destructor can undef them. But that shouldn't pose a problem for p6c. Now, I admit that I've handwaved the tricksy bit, which is, How do you know, Larry, that substr() wants 5`Codes rather than 5`Meters? It's all very well if you have a single predeclared subroutine and can look at the signature at compile time, but you wrote those as multi methods up above, so we don't know the signature at compile time. Well, that's correct, we don't know it at compile time. But what *do* we know? We know we have a number, and that it was generated in a context where, if you use it like a string position, it should turn into a number of code points, and if you use it like a weight, it should turn into a number of kilograms (or pounds, if you're NASA). I don't see the need for all this. Make a C«coerce:as(Int,StrLen)» as mentioned above, and the MMD should be able to figure out that it can take the Int peg and hammer it into the StrLen hole. Then leave it up to the coerce sub to complain if the Int happens
S28ish [was: [Pugs] A couple of string interpolation edge cases]
On Sat, Mar 26, 2005 at 02:11:29PM +0800, Autrijus Tang wrote:
: On Fri, Mar 25, 2005 at 10:03:45PM -0800, Larry Wall wrote:
: Hmm, well, if it got that far. Given strict being on by default,
: this particular example should probably just die on the fact that $
: isn't declared, since there's no $ in Perl 6.
:
: Is $ okay as a variable name? Is everything from perlvar.pod legal? :)
Considering nobody's written perlvar.pod for Perl 6 yet, yeah, everything
in that pod is legal. :-)
: my $ = 3;
:
: Pugs parses that because it only considers $! and $/ as legal
: symbolic variable names.
$! will be a legal variable name. $/ is going away, as is $, which
means they fail under use strict, but they'd still autocreate
globals under laxity as Perl 5 does. (I know Perl 5 exempted all
special variables from strict, but I don't see why we have to do
that for Perl 6. Merely having $_ in the lexical scope or $*! in the
global scope should be sufficient declaration to get around strict.
Though perhaps we can exempt people from having to write $*! under
strict. In fact, that probably goes for all predeclared $* names,
so $IN is legal for $*IN as long as you don't have my $IN hiding
it. Another way to look at it is that * variables are basically
autodeclared our implicitly in the outermost lexical scope.)
Sigh, I'd better rough it all in here, even if I don't have time to
do a good job on it. Maybe somebody can beat this into a real S28 pod.
$? and $@ are gone, merged in with $!. (Frees up ? twigil for $?FOO
syntax.) $^E is merged too. $! is an object with as much info as
you'd like on the current exception (unthrown outside of CATCH, thrown
inside). Unthrown exceptions are typically interesting values of undef.
$$ is now $*PID. ($$foo is now unambuous.)
$0 is gone in favor of $*PROGRAM_NAME or some such.
Anything that varied with the selected output filehandle like $|
is now a method on that filehande, and the variables don't exist.
(The p5-to-p6 translator will probably end up depending on some
$Perl5ish::selected_output_filehandle variable to emulate Perl 5's
single-arg select().) Likewise $/ and $. should be attached to
a particular input filehandle. (In fact, $/ is now the result of
the last regular expression match, though we might keep the idea of
$. around in some form or other just because it's awfully handy for
error messages. But the localizing $. business is yucky. We have
to clean that up.)
All the special format variables ($%, $=, $-, $:, $~, $^, $^A, $^L)
are gone. (Frees up the = twigil for %= POD doc structures and
old __DATA__ stream, the : twigil for private attributes, and the ~
twigil for autodeclared parameters.)
$`, $', and $+ don't exist any more, but you can dig that info out
of $/'s structures. Shortcuts into $/ include $1, $2, and such, and
the newfangled $foo things. Also, $ is changed to $0 for the whole
matched string. $` and $' may be $pre and $post, but you probably
have to explicitly match pre and post to get them remembered,
so we don't have a repeat of the Perl 5 sawampersand fiasco. pre
and post would automatically exclude themselves from $0. Or you
need some special flag to remember them, maybe.
%+ and %- are gone. $0, $1, $2, etc. are all objects that know
where they .start and .end. (Mind you, those methods return magical
positions that are Unicode level independent.)
$* and $# have been deprecated half of forever and are gone. $[
is a fossil that I suppose could turn into an evil pragma, if we
try to translate it at all. (Frees up * twigil for $*FOO syntax.)
$(, $), $, and $ should all change to various $*FOO names. $] is either
something in $* or a trait of the Perl namespace. Likewise $^V, if
they aren't in fact merged.
${...} is reserved for hard refs only now. ($::(...) must be used
for symbolics refs.) ${^foo} should just change to $*foo or $*_foo
or some such.
$; is gone because the multidim hash hack is gone. $ is gone,
replaced by @foo.join(:) or some such. Likewise for $, in print
statements.
We never did find a use for $}, thank goodness.
And we still are keeping $_ around, though it's lexically scoped.
Let's see, what other damage can we do to perlvar. $a and $b are
no longer special. No bareword filehandles. $*IN, $*OUT, $*ERR.
Args come in @*ARGS rather than @ARGV. (Environment still in %ENV,
will wonders never cease.) I don't know whether @INC and %INC will
make as much sense when we're looking installed modules in a database,
though I suppose you still have to let the user add places to look.
%SIG is now %*SIG. The __DIE__ and __WARN__ hooks should be brought
out as separate *ON_DIE and *ON_WARN variables--they really
have nothing to do with signals. I suppose we could even do away
with %SIG and replace it with *ON_SIGINT and such, though then we'd
lose a bit of signal introspection which would have to be provided
some other way. Oh, and we probably ought to split out ?ON_PARSEERROR
from $*ON_DIE to
Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]
Larry Wall creates Sish28:
On Sat, Mar 26, 2005 at 02:11:29PM +0800, Autrijus Tang wrote:
: On Fri, Mar 25, 2005 at 10:03:45PM -0800, Larry Wall wrote:
: Hmm, well, if it got that far. Given strict being on by default,
: this particular example should probably just die on the fact that $
: isn't declared, since there's no $ in Perl 6.
:
: Is $ okay as a variable name? Is everything from perlvar.pod legal? :)
Considering nobody's written perlvar.pod for Perl 6 yet, yeah, everything
in that pod is legal. :-)
: my $ = 3;
:
: Pugs parses that because it only considers $! and $/ as legal
: symbolic variable names.
$! will be a legal variable name. $/ is going away,
By which you mean that $/ is turning into a special $0.
Anything that varied with the selected output filehandle like $|
is now a method on that filehande, and the variables don't exist.
(The p5-to-p6 translator will probably end up depending on some
$Perl5ish::selected_output_filehandle variable to emulate Perl 5's
single-arg select().)
I think $| et al. could just translate to methods on $*OUT, and select
would look like this:
sub perl5_select($fh) {
$*OUT = $fh;
}
Is there some subtlety that that doesn't cover?
%+ and %- are gone. $0, $1, $2, etc. are all objects that know
where they .start and .end. (Mind you, those methods return magical
positions that are Unicode level independent.)
Uh, it might be a bad idea to make $# objects. It might not, but it
might. I think it would be fine if they turned into regular strings
upon assignment (and to pass their full objecthood around, you'd have to
backwhack them). But the problem with keeping them objects is that if
you put them somewhere else and change them, they turn back into regular
strings without .start and .end, which may be a hard-to-track-down bug
if you're thinking that they stay objects... haven't really thought
about this much (and my head is irritatingly foggy at the moment).
$; is gone because the multidim hash hack is gone.
Funny, I never used the multidim hash hack, I just emulated it:
$hash{$foo$;$bar} = $value;
We never did find a use for $}, thank goodness.
Isn't that the enable all of Damian's unpublished modules variable?
$^W is is too blunt an instrument even in Perl 5, so it's probably gone.
Well, almost. When writing a recent module, I found that one of the
modules I was using was spitting out an error from its own internal code
on one of my calls, and there was nothing wrong with the call. I
submitted a bug report to the author, and searched for a way to shut it
up so my users wouldn't complain at me. It ended up having to use $^W
at compile time (and it looks very hackish). We ought to have a
(perhaps not quite as hackish) ability to say there's no reason for
that warning, but I can't modify your code, so just be quiet.
I'm not quite sure what to do with $^N or $^R yet. Most likely they
end up as something $fooish, if they stay.
For $^N, how about $/[-1]?
Luke
Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]
On Sat, 2005-03-26 at 00:27 -0800, Larry Wall wrote:
$$ is now $*PID. ($$foo is now unambuous.)
$0 is gone in favor of $*PROGRAM_NAME or some such.
You know, Java did one thing in this respect that I liked, and managed
to do it in a way that I couldn't stand. The idea of program as object
was nice, but they made the programmer manage it, which was really kind
of silly.
If you think of the OS-level shell around a Perl interpreter as an
object, and make perl manage that for you, then this falls out rather
nicely:
$*PID := $*PROC.pid;
$*PPID := $*PROC.ppid;
$*PROGRAM_NAME := ~$*PROC;
Perhaps even some often-used data could be shoved in there:
$life = time() - $*PROC.start_time;
In fact, it seems like a good place for any OS-level globals:
$*IN := $*PROC.pio_in // $*PROC.stdin;
If we consider $*PROC to be the invocant of the implicit main, then:
say I am number {.pid}, who is number 1?;
works just fine in global context. This also gives you a nice simple way
to drill down into your interpreter / runtime / VM / whatever state:
say I'm {.name} running under {.interp.name};
Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]
On Sat, Mar 26, 2005 at 03:37:41AM -0700, Luke Palmer wrote:
: $! will be a legal variable name. $/ is going away,
:
: By which you mean that $/ is turning into a special $0.
I'd say that $0 is a specialization of $/, but yes, basically, they
both represent the current match result, albeit differently. $0 is
explicitly what would have been returned by $1 if you'd put parens
around the entire match, which is not quite the same as the complete match.
result.
: Anything that varied with the selected output filehandle like $|
: is now a method on that filehande, and the variables don't exist.
: (The p5-to-p6 translator will probably end up depending on some
: $Perl5ish::selected_output_filehandle variable to emulate Perl 5's
: single-arg select().)
:
: I think $| et al. could just translate to methods on $*OUT, and select
: would look like this:
:
: sub perl5_select($fh) {
: $*OUT = $fh;
: }
:
: Is there some subtlety that that doesn't cover?
Like, it renders standard output nameless? In Perl 5, the selected output
handle is a level of indirection above the standard names for the streams
attached to fd 0, 1, and 2. Saying select(FH) doesn't change the meaning
of STDOUT.
: %+ and %- are gone. $0, $1, $2, etc. are all objects that know
: where they .start and .end. (Mind you, those methods return magical
: positions that are Unicode level independent.)
:
: Uh, it might be a bad idea to make $# objects. It might not, but it
: might. I think it would be fine if they turned into regular strings
: upon assignment (and to pass their full objecthood around, you'd have to
: backwhack them). But the problem with keeping them objects is that if
: you put them somewhere else and change them, they turn back into regular
: strings without .start and .end, which may be a hard-to-track-down bug
: if you're thinking that they stay objects... haven't really thought
: about this much (and my head is irritatingly foggy at the moment).
My head is always irritatingly foggy. :-)
Anyway, I'm think of them more as COW objects, and they'd have to know
if their original string was yanked out from under them in any case, so
that's probably the correct moment to invalidate .start and .end, if
we even bother.
: $; is gone because the multidim hash hack is gone.
:
: Funny, I never used the multidim hash hack, I just emulated it:
:
: $hash{$foo$;$bar} = $value;
Well, guess how we'll emulate it in Perl 6. :-)
: We never did find a use for $}, thank goodness.
:
: Isn't that the enable all of Damian's unpublished modules variable?
Shh. Impressionable people are listening.
: $^W is is too blunt an instrument even in Perl 5, so it's probably gone.
:
: Well, almost. When writing a recent module, I found that one of the
: modules I was using was spitting out an error from its own internal code
: on one of my calls, and there was nothing wrong with the call. I
: submitted a bug report to the author, and searched for a way to shut it
: up so my users wouldn't complain at me. It ended up having to use $^W
: at compile time (and it looks very hackish). We ought to have a
: (perhaps not quite as hackish) ability to say there's no reason for
: that warning, but I can't modify your code, so just be quiet.
Yes, we need to be able to suppress warnings in dynamic scopes as well
as lexical, but that's probably not a scalar proposition anymore, unless
the replacement for $^W is taken as a pointer to a hash of potential
warnings. Presumably you could temporize the whole hash to suppress
all warnings, or individual elements to suppress individual warnings.
But maybe that's a good place for temporized methods instead, and then
we could name sets of warnings. Or maybe there's yet some other approach
that makes more sense. We want to encourage people to suppress only
the exact warnings they want to suppress, and not just cudgel other
modules into silence.
: I'm not quite sure what to do with $^N or $^R yet. Most likely they
: end up as something $fooish, if they stay.
:
: For $^N, how about $/[-1]?
I guess that makes some sense. I was thinking of $/[-$n] as relative
to the current match position, but hadn't thought it through to the
point of deciding how to count those. $^N mandates counting based on
right parentheses rather than left, which I guess makes sense. So
let's say that $/[-2] means (one) rather the incomplete ((three)two):
/(one)((three) { $/[-2] } two)
I note that this is another difference between $/ and $0, since $/
is representing the current state of the match, while $0 isn't bound
till the match succeeds (unless you explicitly bind it earlier, which
is yet another difference between $0 and $/, since you can't bind $/
to mean a portion of itself).
Larry
Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]
Larry Wall wrote: %+ and %- are gone. $0, $1, $2, etc. are all objects that know where they .start and .end. (Mind you, those methods return magical positions that are Unicode level independent.) How can you have a level independent position? The matching itself happens at a specified level. (Note that which level the match happens at can change what is matched.) So it makes sense that all the positions that come out of it are in terms of that level. Now, that position can be translated to a lower level, but not to an upper level, since you can happily land in the middle of a char. This is part of what I'm having trouble with your concept of a Str being at several levels at once: There's no reliable way to have a notion of position, expect to have it as attached to the highest possible level, and the second someone does something at lower level, you void the position, and possibly the ability to remain at that high level. I still see my notion of a Str having only one level and encoding at a time as being preferable. Having the ability to recast a string to other levels/encoding should be easy, and many builtins should do that recasting for you. I do _not_ see $/ friends getting ported across a recasting. .pos can be translated if new level = old level, otherwise gets set to undef. Please convince me your view works in practice. I'm not seeing it work well when I attempt to define the relevent parts of S29. But I might just be dense on this. -- Rod Adams
Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]
On Sat, Mar 26, 2005 at 09:59:10AM -0500, Aaron Sherman wrote:
: On Sat, 2005-03-26 at 00:27 -0800, Larry Wall wrote:
:
: $$ is now $*PID. ($$foo is now unambuous.)
:
: $0 is gone in favor of $*PROGRAM_NAME or some such.
:
: You know, Java did one thing in this respect that I liked, and managed
: to do it in a way that I couldn't stand. The idea of program as object
: was nice, but they made the programmer manage it, which was really kind
: of silly.
Well, there is a process object, but it actually exists inside the
operating system. It's a little silly to force people to name their
own process all the time. I think we can assume that global variables
belong to the current process, sort of on the you're soaking in it
principle.
: If you think of the OS-level shell around a Perl interpreter as an
: object, and make perl manage that for you, then this falls out rather
: nicely:
:
: $*PID := $*PROC.pid;
: $*PPID := $*PROC.ppid;
: $*PROGRAM_NAME := ~$*PROC;
:
: Perhaps even some often-used data could be shoved in there:
:
: $life = time() - $*PROC.start_time;
:
: In fact, it seems like a good place for any OS-level globals:
:
: $*IN := $*PROC.pio_in // $*PROC.stdin;
We can certainly have various objects proxying for various contexts.
It's not clear how those should be broken out though. To me, an OS
isn't a process, and there's not necessarily going to be a one-to-one
correspondence.
: If we consider $*PROC to be the invocant of the implicit main, then:
:
: say I am number {.pid}, who is number 1?;
:
: works just fine in global context. This also gives you a nice simple way
: to drill down into your interpreter / runtime / VM / whatever state:
:
: say I'm {.name} running under {.interp.name};
That's an interesting idea, the more so now that we're leaning away
from .foo ever assuming the current topic unless it also happens to
be the invocant. But it probably wouldn't do to have one common name for
the .pid outside of methods and force people to use a different name
inside methods. Here's where $*PID works much better, because it can
be the same everywhere.
Larry
Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]
On Sat, 2005-03-26 at 12:48 -0800, Larry Wall wrote:
On Sat, Mar 26, 2005 at 09:59:10AM -0500, Aaron Sherman wrote:
Well, there is a process object, but it actually exists inside the
operating system. It's a little silly to force people to name their
own process all the time. I think we can assume that global variables
belong to the current process, sort of on the you're soaking in it
principle.
That seems to be a self-limiting position. It leads (as it did in Perl
5) to a desire to reduce the number of times you add access to new OS
features (as it requires global namespace suckage, though not as bad as
in Perl 5), and you'll still split out an object, module or data
structure to contain all of the information that's not in Perl proper
because it's platform specific (e.g. current drive letter context under
DOS).
I agree that $*PID is a useful alias for $*PROC.pid (though the extra *
still bothers me), but providing a unified API for interacting with
myself as an OS-level construct seems to make sense.
That's perhaps just my preference. I'm a hybrid OO/procedural guy, so I
tend to reach into the OO toolbox whenever I think it will make my life
easier.
: If you think of the OS-level shell around a Perl interpreter as an
: object[...]
We can certainly have various objects proxying for various contexts.
It's not clear how those should be broken out though. To me, an OS
isn't a process, and there's not necessarily going to be a one-to-one
correspondence.
True enough, and you would certainly NOT:
my $sock = $*PROC.socket;
That makes no sense at all. However, things like what IO layer am I
using or am I a thread are perfectly valid questions to pose of a
process abstraction.
: If we consider $*PROC to be the invocant of the implicit main, then:
:
: say I am number {.pid}, who is number 1?;
That's an interesting idea, the more so now that we're leaning away
from .foo ever assuming the current topic unless it also happens to
be the invocant. But it probably wouldn't do to have one common name for
the .pid outside of methods and force people to use a different name
inside methods. Here's where $*PID works much better, because it can
be the same everywhere.
Well, it's always:
$*PROC.pid
The invocant goodness is just handy in a certain circumstance (what *is*
main's invocant, out of curiosity? I guess it could be the interpreter
context, but that should probably have some relationship to your process
info anyway (either is or does ... probably does.) If I were writing
Learning Perl 6, I would teach $*PID and/or $*PROC.pid, but not
.pid.
Re: S28ish [was: [Pugs] A couple of string interpolation edge cases]
On Sat, Mar 26, 2005 at 02:37:24PM -0600, Rod Adams wrote: : Larry Wall wrote: : : %+ and %- are gone. $0, $1, $2, etc. are all objects that know : where they .start and .end. (Mind you, those methods return magical : positions that are Unicode level independent.) : : How can you have a level independent position? By not confusing positions with numbers. They're just pointers into a particular string. : The matching itself happens at a specified level. (Note that which level : the match happens at can change what is matched.) So it makes sense that : all the positions that come out of it are in terms of that level. When we're dealing with mostly variable length encodings, it makes more sense that the positions come out as string pointers that only convert to numbers grudgingly under duress. If you're just going to feed a position back into a substr() or as the start position of the next index(), there's no reason to translate it to a number and back to a pointer. It's a lot more efficient if you don't. : Now, that position can be translated to a lower level, but not to an : upper level, since you can happily land in the middle of a char. I talked about this problem in one of the As. I think the fail soft approach is to round to the next ceiling boundary and issue a warning. : This is part of what I'm having trouble with your concept of a Str being : at several levels at once: There's no reliable way to have a notion of : position, expect to have it as attached to the highest possible level, : and the second someone does something at lower level, you void the : position, and possibly the ability to remain at that high level. A position that is a pointer can be true for all levels simultaneously. It has the additional benefit of a type that is subtype constrained to operate with other values from the same string, so if you subtract two pointers from different strings, you can actually detect the error. : I still see my notion of a Str having only one level and encoding at a : time as being preferable. Having the ability to recast a string to other : levels/encoding should be easy, and many builtins should do that : recasting for you. And I still see that you can have your view if you install a pragma that forces all incoming strings to a single level. But I think we can do that lazily, or not at all, in many cases. The basic underlying problem is that there is no simple mapping from math to Unicode. The language that lets people express their solution in terms of Unicode instead of in terms of math is going to have a leg up on the future, at least in the Unicode problem space. Strings were never arrays in Perl, and they're only getting further apart as the world makes greater demands on strings to represent human language. So I'd much rather introduce an abstraction like string position now that is not a number. It's a dimensional value, where the scaling of the dimensionality is bound to a particular string. You can have a pragma that says, Untyped numbers are assumed to be meters, kilograms, and seconds, and a different lexical scope might have a pragma that says Untyped numbers are assumed to be centimeters, grams, and seconds. These scopes can get along as long as they don't try to exchange untyped integers. Or if they do, they have some way of ascertaining what an untyped integer meant when it was generated. : I do _not_ see $/ friends getting ported across a recasting. .pos can : be translated if new level = old level, otherwise gets set to undef. The interesting thing about a pointer is that you can pass it through a higher level transparently as long as you don't actually try to use it. But if you do try to use it, I think undef is overkill. Just as a float stuffed into an int truncates, we should just pick a direction to find the next boundary and go from there, maybe with a loss of precision warning. The right way to suppress the warning would be to install an explicit function that rounds up or down. : Please convince me your view works in practice. I'm not seeing it work : well when I attempt to define the relevent parts of S29. But I might : just be dense on this. Well, let's work through an example. multi method substr(Str $s: Ptr $start, PtrDiff ?$len, Str ?$repl) Depending on the typology of Ptr and PtrDiff, we can either coerce various dimensionalities into an appropriate Ptr and PtrDiff type within those classes, or we could rely on MMD to dispatch to a suite of substr implementations with more explicit classes. Interestingly, since Ptrs aren't integers, we might also allow multi method substr(Str $s: Ptr $start, Ptr ?$end, Str ?$repl) which might be a more natural way to deal with variable length encodings, and we just leave the lengthy version in there for old times sake. We could go as far as to allow a range as the second argument: $x = substr($a, $start..^$end); or its evil twin: $x = $a[$start..^$end]; Of course,
Re: String 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
String interpolation
On Tue, 2004-07-20 at 13:15, Juerd wrote:
The Perl 6 Summarizer skribis 2004-07-20 14:46 (+0100):
Wasn't there an actual thread to respond to for this? I always feel odd
turning the summary into a thread on what it's summarizing.
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.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Perl Toolsmith
http://www.ajs.com/~ajs/resume.html
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
string interpolation
Hello, I was reading stuff on the perl6 web site, and had some ideas about
string interpolation rules. Is this a place to send this?
String interpolation should be controlled by the programmer on a string by
string basis, or on more global quote-type by quote type basis.
---
scenario one, object.method format
---
Lets pretend a string is an object. The normal value of the string is the
interpolation of the string using the default rules for the quotes used.
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($) ;
The .interpolate method would have the additional ability to interpolate the
contents of a variable.
$result = $string.interpolate; # some type of interpolate, probably
like
$result = $string.interpolate(${}); # interpolate scalar vars
surrounded by {}'s
you could imagine allowing more complex rules, such as mapping
interpolations to user defined functions, or only interpolating defined
variables, otherwise leave them as-is, or perhaps allowing you to map
specific variables to values but just for that one string's interpolation
# only interpolate defined variables
$result = $some $of $these $will $be
$interpolated.interpolate(defined($)) ;
# interpolate, one variable gets a specific value
$result = $one $two $three.interpolate('$one'='hi there') ;
# interpolate, scalar values come from user defined function
$result = $one $two $three.interpolate($ = \my_function) ;
Here's some more examples
# normal interpolation (i.e. none in ' quotes)
$result = 'string with $var';
# override the ' defaults
# use the $ rule, which would mean interpolate scalars just
# as we do today in strings
$result = 'string with $var' . interpolate($);
# use the ${} rule, which would mean interpolate scalars,
but
# only when bracketed (using {})
$result = 'string with ${var}' . interpolate(${});
# allow a function to interpolate in scalar context
# by using the rule combined with $-with-round-brackets
rule
# the function parameters would not be interpolated,
$result = 'string with $(my_function($one,$two))' .
interpolate($());
# allow a function to interpolate in array context
# by using the rule combined with @-with-round-brackets
rule
$result = 'string with @(my_function($one,$two))' .
interpolate(@());
# allow a function to interpolate in scalar context
# by using the rule combined with $-with-round-brackets
rule
# and also let the function parameters be interpolated
$result = 'string with $(my_function($one,$two))' .
interpolate($());
# nested interpolation rules.
# We force regular scalar interpolation on one of the
parameters
# overriding the default ' interpolation rules
$result = 'string with $(my_function('$one'.interpolate($)
,'$two'))'
. interpolate($());
You could set the default interpolation on a quote-type basis for a scope.
# allow qq{} to always do scalar, array, and function
interpolation,
# but only if the scalar is surrounded by //, the array by
{}, and
# the function by
use interpolate 'qq' = '$//@{}$' ;
$result = $this does *not* @interpolate $(at{'all'});
$result = $/this/ *does* @{interpolate} $at{'all'};
---
scenario two, same idea but using =~ notation.
---
A string could have interpolation rules applied to the string. The rules
would not modify the string, just the value seen by when the value is
extracted. That's not an issue in a simple quoted string, but makes a
difference if you interpolate a variable
$result = this $is_not interpolated, but ${this_is} =~ i/${}/;
$result1 = $master_copy =~ i/${}/; # get the result of
interpolating ${} vars
$result2 = $master_copy =~ i/@/;# get the result of
interpolating @ vars
$0.02
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
