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
