This weeks summary, part 2
The Perl 6 summary for the week ending 2006-02-12 Did I say Thursday night? What was I thinking? Blame Nikon for finally delivering my D200; or just blame me for being a lazy git who spent Thursday night recovering from the drive home from Liverpool and Friday playing with a new toy and chatting to interesting people in the atrium at SageGateshead. So, here's part two of the summary, in which I summarize ancient history in perl6-language. This week in perl6-language Overloading the variable declaration process Darren Duncan asked that Perl 6 provide a way for a class/role/metaclass to declare that all variables declared to be of that type are automatically/implicitly set to a particular value at declaration time. Larry's response was fascinating as he talked about what I find myself thinking of a continuum of definedness, where, instead of worrying if a variable is defined, the language/programmer/whatever only cares whether it is defined enough. The syntax for asking such questions isn't really defined enough yet. Then it all got slightly philosophical with talk of the ideal of a dog (when I think the questioner really wanted to talk about the ideal dog), Platonism and Aristotelianism. And the metamodel. And there was hypnotism. http://xrl.us/j36z Macros? Last week, Brad Bowman asked a bunch of questions about the workings of Perl 6 macros. This week, Larry offered answers. http://xrl.us/j362 A proposition for streamlining Perl 6 development Yuval Kogman had some ideas about how to make Perl 6 development go faster. Igor! More tuits! Some people disagreed with him. Some agreed. I am staying well out of this one (at least in the summaries; I have opinions and I don't trust them, or myself, enough to be able to write a properly impartial summary of the discussions). http://xrl.us/j363 Tokenizer hints, supporting delimited identifiers or symbols Darren Duncan had another wish for Perl 6: a simple and terse way for Perl 6 identifiers or symbols to be able to be composed of any characters whatsoever... whoa! Deja vu! Ah yes, I already did this one in part one. Move right along the summary, nothing to see here. http://xrl.us/j364 The definition of say Simple question: how do you implement say? The answer isn't quite as simple as you might think. Actually, that's not true, the answer is simple, but the question has hidden depths. Go read Robin Houston's question and its responses if you don't believe me. http://xrl.us/j365 Smart match table Robin Houston had some questions/observations about the smart match table in synopsis 4. This is the table that describes how the smart match (~~) operator does its comparisons. It turns out that the table in the synopsis implies non-commutative behaviour, which came as something of a surprise. I'm surprised this thread petered out so quickly without any real resolution; it seems rather important to me. http://xrl.us/j366 Acknowledgements, apologies and everything else So, does the serial format work? Apart from the problem of not actually getting on with part two when I should have done, it works remarkably well for me. Writing the summary in one big chunk can be somewhat daunting, especially if my brain gets fried by the first two lists. Feedback is good. Help Chip http://geeksunite.org/ -- Chip still needs help. The usual coda If you find these summaries useful or enjoyable, please consider contributing to the Perl Foundation to help support the development of Perl. http://donate.perlfoundation.org/ -- The Perl Foundation The Perl Foundation Blog is an excellent source of news about the Perl Foundation's activities. http://blog.perlfoundation.org/ Planet Perl Six is a handy news aggregator of several Perl 6 related sources. http://planet6.perl.org/ http://dev.perl.org/perl6/ -- Perl 6 Development site Check out my website, it's lovely. http://www.bofh.org.uk/ -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/
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: CODE {...} mentioning variables without interpolation
On 18/02/06 03:10, Larry Wall wrote:
On Sat, Feb 18, 2006 at 01:57:18AM +0200, Brad Bowman wrote:
: $a is spliced into the say as either a string or AST, not
: as a runtime use of $a. If the snippet was:
:
: $a = '$a';
: return CODE { say $a };
:
: Then we'd (eventually) get a non-splicing mention of $a, one that
: would refer to the $a in scope at the macro call, I think.
: Is this correct?
No. If bare $a is not found in the CODE's scope, it must *bind* to
an existing $a in the macro caller's scope as a runtime use of $a,
I was intending the above example to satisfy the $a in the CODE's scope
clause, I was missing a my. I think my example doesn't achieve
it's goal anyway. I'll try again:
macro M ($a) {
my $b = '$c';
return CODE { $a + $b };
}
package Elsewhere;
my ($b, $c, $d) = (1,2,3);
say M($d + 2);
The macro parameter $a is bound to the ast for COMPILING::$d + 2
The $a mentioned in the CODE is replace with the same, roughly:
CODE { COMPILING::$d + 2 + $b }
$b exists in the lexical scope of the CODE block, so it is preferred.
Since $b is a string, '$c' replaces $b in the above and parsing
is restarted there. Once $c is parsed, the macro's scope is searched
and fails. (This is where I derailed the first time round)
CODE { COMPILING::$d + 2 + $c }
The $c is free and so must bind to an existing $c in the scope of the
macro call, which is fine in this example. The result is a complicated 7.
I guess I was unclear about the effect of the $b='$c' indirection,
it seems like the answer is that there is no effect, the $c is
bound and spliced just as the original $b is.
or the macro fails. If the calling code wants to supply arguments
to the macro body, they must come in as ordinary arguments, or use
some modifier that chases up the dynamic stack, such as one of
CALLER::$a
ENV::$a
COMPILING::$a
These are non-splicing mentions of variables from the call site (right?).
Is there a way to do a non-splicing mention of variables at the macro
definition site, similar to normal code closures?
The CODE can mention sub names, they're not spliced and thus give the
indirection I was looking for. (I think)
my $counter;
sub inc_counter { return $counter++; }
macro c {
return CODE { inc_counter() };
}
A state variable declared within the CODE would also suffice in this case.
: --
: When one is not capable of true intelligence, it is good to consult with
: someone of good sense. -- Hagakure http://bereft.net/hagakure/
It's not entirely clear to me that we should trust the advice of someone
who was prevented from committing seppuku only by edict of Tokugawa. :-)
Yeah! Where's his mettle?
But the scary part about that quote is that it seems to be saying that
if you have true intelligence you don't need good sense.
Maybe it was lost in translation. Or maybe those of true intelligence
can work it out themselves, without needing the advice of a cranky samurai. :)
--
... 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
