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

Brad Bowman asked:

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

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 {
           ,{@list_of_code_lines.join(';')}
       }
   };

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 <pdcaw...@bofh.org.uk>
http://www.bofh.org.uk/

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

On 18/02/06 07:49, Damian Conway wrote:

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 $%@{ 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

On 18/02/06 12:23, Jonathan Lang wrote:

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

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 {
          `{@list_of_code_lines.join(';')}
      }
  };

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

On 19/02/06 03:48, Jonathan Lang wrote:

Here-docs are usually safe to quote any amount of line noise,
but I take your point.

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.

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 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/

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.

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