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
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
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
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 s
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:
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: Ins
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
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
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
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
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.
:
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
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 meth
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 le
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
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 m
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. (No
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 di
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
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
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
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, ther
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
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 cha
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
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 st
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 co
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:
> : >
> : > m
On Thu, Jul 22, 2004 at 08:23:21AM +0200, Juerd wrote:
: Larry Wall skribis 2004-07-21 12:25 (-0700):
: > I'm inclining more towards the "only interpolate things that end with
: > brackets or parens" rule. That would allow $foo.bar() to interpolate,
: > but not $foo.bar.
:
: Anything that is deci
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"
: lite
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 PRO
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
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()
: >
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 th
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 peo
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()
> &foo&foo(1)
@foo@foo.join(" ")
Yes?
/me idly wonders whether map an
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 interp
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 natural
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
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[]"
Jonathan Scott Duff wrote:
Surely you mean [EMAIL PROTECTED] instead of 0..Inf
I think the iterator implicit in array slicing should, and could, be
smart enough to return when there's nothing more to iterate. Considering
the following code:
@foo = (1, 2, 3);
@bar = @foo[1..Inf];
@bar should
r. 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
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
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
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}
{
Larry Wall skribis 2004-07-21 12:25 (-0700):
> I'm inclining more towards the "only interpolate things that end with
> brackets or parens" rule. That would allow $foo.bar() to interpolate,
> but not $foo.bar.
Anything that is decided by something's end makes things hard to read,
hard to learn and
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."
"T
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 expression
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
> "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
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 inte
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, pe
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]
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)
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 @fo
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
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[
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 {}.
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 PROTECTE
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
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 s
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 b
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
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[*
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 li
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,
--- 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
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
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 cat
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 stri
"Chromatic" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Shh, no one's let slip the idea of curried roles yet! I'm not even
> certain A12 mentioned parametric roles, let alone first-class roles.
And with parametric roles, perhaps we also get C roles?
Dave.
"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 a
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
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
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
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:
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}
> "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
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 earl
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
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 inte
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
82 matches
Mail list logo
