Re: Concerns about {...code...}
On Thu, Dec 20, 2007 at 03:24:30PM -0800, Michael G Schwern wrote:
: Jonathan Scott Duff wrote:
: On Thu, Dec 20, 2007 at 07:58:51AM -0500, Mark J. Reed wrote:
: I think the issue is that bare vars don't interpolate anymore, but
: they still have sigils of their own, so adding to the default interp
: syntax is too noisy: ${$var} is not really much improvement over
: ${\(expr)}.
:
: That's not quite accurate. Scalars interpolate as they always have, but
: aggregates need to be followed their respective bracketing construct
: (e.g., My array contains these items: @array[])
:
: The only issues that I see from the original email are:
: 1. interpolating scalars but not code
: 2. having to be more careful about what type of string you're using
:
: Adriano answered #1 I think: $yaml = Q:!c{ $key: 42 };
:
: For the second one, if you're really just worried about how prevalent {}
: appear in double-quotish strings, perhaps @Larry could be persuaded to
: make them non-interpolative by default. (i.e., the adverb would be
: required to make them interpolate)
:
: That pretty much sums up my concern.
Well, it's certainly a concern that we thought about a lot when
designing the interpolation originally, so I rather suspect I'm highly
unlikely to change my mind on this one. I've done (and read) a fair
amount of pugs programming since then, and while I can see that from a
Perl 5 perspective it looks like a problem, the situation doesn't arise
so often in practice, and when it does, it almost always results in
a compile-time error (which is a good thing). Perl 6 balances a lot
of subtle issues differently than Perl 5 does, and these all factor into
whether closures should interpolate by default or not. More on that
below.
But I will make one general remark at the start, which is that we
want Perl 6 programmer to look at curlies differently than Perl 5
programmers do. In Perl 5, curlies were overloaded many different
ways, and rarely did they mean a closure by themselves. In Perl 6,
it's almost always the case that bare curlies indicate a closure of
some sort throughout the rest of the language. So the visual and
psychological import of seeing and typing curlies is intentionally
weighted rather differently. Curlies are Perl 6's lambda. Whenever
the user sees curlies, we want them to stop and think. Even the
curlies used by the built in control operators are real lambdas
in the abstract, unlike in P5 where they are just hardwired in the
grammar. Bare curlies in regex are now special too.
(Going the other way, you'll note that, in various other spots where
P5 uses curlies such as in \x{...} or $x{foo}, P6 prefers things like
\x[...] or $xfoo instead, to avoid the visual implication of code.)
: The gyrations to turn off interpolating code... it's nice to know that exists
: but not something I want to ever have to remember or type or even consider my
: quoting context.
In general, I would never use negative form myself. I'd be much more
likely to use qs// than qq:!c//. But since the negative adverbial
forms are already available, it seems better to go ahead and provide
them to work as expected, even if they inspire occasional nausea.
As for the Q base form, it's not really there so much for end-use,
but to provide the bare form from which all other quotes and quote-like
forms are constructed, including forms like rx//. Most user-defined
quotes should just be variants of q//. Or just use bare '' quotes,
since it's still possible to interpolate using \qq[$foo]. This is
huffmanly suitable for quoting large stretches of code that need only
occasional interpolations.
: Interpolate vs not interpolate is enough, I have more
: important things to worry about while coding. [1]
And, in fact, this can be taken as an argument for making closures
interpolate consistently in double quotes, if they interpolate at all.
To the first approximation, double quotes do all interpolations
and single quotes do none (ignoring backslashes). Positioning the
double quote semantics somewhere in the middle of the spectrum just
means you have to memorize which sequences interpolate by default
and which don't. And we're trying to avoid the need for the user to
memorize arbitrary lists.
: Non-interpolative by default... well I don't exactly want the feature to go
: away either. [2] I can see its uses [3] and it potentially eliminates some
: otherwise convoluted bits of code. And again, I don't want to be thinking
: about flipping interpolation features on and off for each string. Even qs//
: is more than I want to consider. [4]
In general, if you're interpolating a bunch of strings similarly,
you want to think about factoring that out. One of the reasons
we're reserving backticks for users is so they can use them for
any specialty quotes, not just for qqx//.
: Code execution in a string is a very powerful thing, so it's not the sort of
: thing one wants to accidentally trigger. Because it's
Re: Concerns about {...code...}
On Dec 21, 2007 8:53 AM, John Siracusa [EMAIL PROTECTED] wrote: FWIW, my reasoning in this area is based on Laziness: single quotes mean I don't have to scan the string looking for interpolated stuff when reading code. Double quotes mean I do, and I'm annoyed at the waste of time when I scan and find nothing. Why didn't this guy just use singles here? It's (mildly) misleading. +1, as the kids these days say. I use singles by default for literal strings. I switch to doubles when I need to interpolate, or for text containing apostrophes (though it would be more consistent to use q[...] in the latter case. I use qq and qw all the time, but rarely q for some reason). The single-quoted string literal has become such a habit that I frequently make mistakes in other C-like languages that use the two types of quotation marks to make the character/string distinction. -- Mark J. Reed [EMAIL PROTECTED]
Re: Concerns about {...code...}
On 12/21/07 5:54 AM, Larry Wall wrote: To you and me, the fact that there are single quotes means there's something there to hide. But other people think the other way and see double quotes as indicating there's something to interpolate. I think PBP comes down on that side, but to me, single quotes are a little harder to see. And maybe there's some bias from seeing double quotes used non-interpolatively in American English. FWIW, my reasoning in this area is based on Laziness: single quotes mean I don't have to scan the string looking for interpolated stuff when reading code. Double quotes mean I do, and I'm annoyed at the waste of time when I scan and find nothing. Why didn't this guy just use singles here? It's (mildly) misleading. (There are obviously edge cases, even in Perl 5, but even naive adherence to this guideline is a good first approximation, with a second look only required in the rarest of cases.) -John
Re: Factoring Arguments
On Fri, Dec 21, 2007 at 08:41:54AM -0800, Jonathan Lang wrote:
and so on, you might do something like:
with qq :(c = false) {
I think this can be done with normal currying, something like
temp circumfix: := quote:qq.assuming(:!c);
-ryan
Factoring Arguments
I'm thinking aloud here, so please bear with me.
A number of languages have a with ... construct that's intended to
cut down on repetitive typing, by factoring the invocant out of every
method call. Perl 6 also has this, in the form of given ...:
given $foo.bar.baz {
.dothis();
.dothat();
.doanother();
}
(same as)
$foo.bar.baz.dothis();
$foo.bar.baz.dothat();
$foo.bar.baz.doanother();
I'm wondering if something similar could be done for optional
arguments - something along the lines of within the following block,
assign value V to argument X of routine R by default. This would
allow for a similar factoring out of repetitive flags. So instead
of:
say qq:!c ... { ... } ...;
say qq:!c ... { ... } ...;
say qq:!c ... { ... } ...;
and so on, you might do something like:
with qq :(c = false) {
say ... { ... } ...;
say ... { ... } ...;
say ... { ... } ...;
}
Or maybe it could be a pragma (which, by definition, lasts only until
the end of the current scope):
{
use defaults { qq = :!c }
say ... { ... } ...;
say ... { ... } ...;
say ... { ... } ...;
}
The core concept here is to allow the programmer to easily change the
default behavior of a routine within a given scope so that he doesn't
have to repeatedly override the default behavior every time it comes
up.
--
Is this reasonable, or is this too much of a corner case to be worth the effort?
--
Jonathan Dataweaver Lang
Re: Factoring Arguments
A number of languages have a with ... construct that's intended to cut down on repetitive typing, I hope I will be excused for dragging in the indecency, but it might be worth looking at the concepts COBOL used to mitigate its verbosity, (e.g. types defined in a structure that get inherited by lower levels, unless specifically over-ridden). Those who will not learn from history are bound to repeat it, and a lot of o-o concepts give me an unpleasant sense of deja vu. -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
Re: Concerns about {...code...}
On Fri, Dec 21, 2007 at 08:59:02AM -0500, Mark J. Reed wrote: : The single-quoted string literal has become such a habit that I frequently : make mistakes in other C-like languages that use the two types of quotation : marks to make the character/string distinction. Yeah, it might be my C background that biases me the other way too. I guess when I'm reading someone else's double-quoted string I don't really feel like I need to check whether it interpolates; it just chunks into a psychological unit that *could* interpolate if it wants to, and I note any obvious literal text and go on from there. I don't feel compelled to analyze the string in depth unless I need to. For someone who is somewhere on the autistic spectrum, I'm pretty good at ignoring details. I understand others may not be so lucky. :) Larry
Re: Concerns about {...code...}
Larry Wall wrote: As for the Q base form, it's not really there so much for end-use, For an operator not intended for end use, it has a remarkable low Huffman rank...
Re: Concerns about {...code...}
On Dec 21, 2007 4:51 PM, Dave Whipp [EMAIL PROTECTED] wrote: Larry Wall wrote: As for the Q base form, it's not really there so much for end-use, For an operator not intended for end use, it has a remarkable low Huffman rank... But since it will be combined with adverbs like my $str = Q :b :s /Hello $name\n/; it needs to be short. Q is just one part of a larger expression that is meant to be taken as a whole.
Re: Concerns about {...code...}
Chas. Owens wrote: On Dec 21, 2007 4:51 PM, Dave Whipp [EMAIL PROTECTED] wrote: Larry Wall wrote: As for the Q base form, it's not really there so much for end-use, For an operator not intended for end use, it has a remarkable low Huffman rank... But since it will be combined with adverbs like my $str = Q :b :s /Hello $name\n/; it needs to be short. Q is just one part of a larger expression that is meant to be taken as a whole. That misses the point of Huffman coding. It is not the length of the overall expression that determines the score: it is the relative frequency with which it will appear in perl6 programs. If the construct is used only rarely then it should have a longer name, and people using it would be well advised to use the long form of the adverbs when they do so -- increasing the overall length of the expression still further as an aid to readability of the rarely used operator. If it will be frequently used then it of course deserves the short name.
Re: Concerns about {...code...}
Dave Whipp wrote: If the construct is used only rarely then it should have a longer name, Actually, Huffman coding implies that if the construct is used regularly then it should have a short name. It does not mandate a long name for rare constructs; it merely says that if a given short name is suitable for both a common construct and a rare construct, the common construct should get it. If there's no such conflict, there's no reason not to give the short name to a rarely used construct. -- Jonathan Dataweaver Lang
Re: Factoring Arguments
Ryan Richter wrote:
Jonathan Lang wrote:
and so on, you might do something like:
with qq :(c = false) {
I think this can be done with normal currying, something like
temp circumfix: := quote:qq.assuming(:!c);
That handles the specific example that I had in mind, but does so in a
rather brittle way. First, the programmer is forced to use
double-quotes to make use of the currying; he cannot switch to another
quoting character if one of the strings that he's dealing with has a
number of double-quote characters in it. This being a
quoting-specific issue, it should be no surprise that it comes with a
quoting-specific solution, e.g., use 'qs' instead of 'qq:!c') - but
that still leaves you with having to prefix every string in the target
scope: cqs ... instead of c ... . Still, that isn't my main
concern here.
There's no way that I know of to override the currying: every
.assuming that you use removes one parameter from the signature (if I
understand currying correctly). This means that you don't get to set
assumed values for three different parameters at the start of the
block and then override just one of them for a single use of the
function in the middle of the block. This concern could probably be
addressed if currying doesn't remove arguments from a signature, but
instead forces them to be optional and assigns default values to them;
but this can lead to its own problems, such as what happens when you
curry the second of three required positional parameters.
What I was thinking of would be somewhat more modest: it would be a
variation on the currying mechanic, but would only apply to optional
parameters. It wouldn't remove them from the signature at all; it
would merely change the default values assigned to them.
--
Jonathan Dataweaver Lang
Re: Concerns about {...code...}
On Fri, Dec 21, 2007 at 01:51:19PM -0800, Dave Whipp wrote: Larry Wall wrote: As for the Q base form, it's not really there so much for end-use, For an operator not intended for end use, it has a remarkable low Huffman rank... That's because some end-users will want to use Q anyway. I figured the shift key requirement was sufficient Huffman coding... :-) Larry
Re: Factoring Arguments
On Fri, Dec 21, 2007 at 08:41:54AM -0800, Jonathan Lang wrote:
: I'm wondering if something similar could be done for optional
: arguments - something along the lines of within the following block,
: assign value V to argument X of routine R by default. This would
: allow for a similar factoring out of repetitive flags. So instead
: of:
:
: say qq:!c ... { ... } ...;
: say qq:!c ... { ... } ...;
: say qq:!c ... { ... } ...;
:
: and so on, you might do something like:
:
: with qq :(c = false) {
: say ... { ... } ...;
: say ... { ... } ...;
: say ... { ... } ...;
: }
Hmm, well, qq isn't really a function, it's actually the name of
a sublanguage, as parsed by a macro.
: Or maybe it could be a pragma (which, by definition, lasts only until
: the end of the current scope):
:
: {
: use defaults { qq = :!c }
: say ... { ... } ...;
: say ... { ... } ...;
: say ... { ... } ...;
: }
I like to name pragmas by the construct they're controlling, so if
we took that approach, I'd probably make it something like:
{
use qq ':!c';
say ... { ... } ...;
say ... { ... } ...;
say ... { ... } ...;
}
: The core concept here is to allow the programmer to easily change the
: default behavior of a routine within a given scope so that he doesn't
: have to repeatedly override the default behavior every time it comes
: up.
:
: --
:
: Is this reasonable, or is this too much of a corner case to be worth the
effort?
Well, sure, but there's really no effort required at all, given you can
already do it (in theory) with:
{
my macro quote: { 'qq:!c' }
say ... { ... } ...;
say ... { ... } ...;
say ... { ... } ...;
}
Actually, the my is a bit redundant there; syntax changes from
macros are always lexically scoped. That includes imports of macros,
so if you made a module that contained:
my macro quote: is export(:DEFAULT) { 'qq:!c' }
then you could use it like this:
{
use Schwernlich;
say ... { ... } ...;
say ... { ... } ...;
say ... { ... } ...;
}
and it would be a lexically scoped language hack. With a slight
generalization it's the use qq pragma above. Welcome to Perl 6. :)
Larry
Re: Concerns about {...code...}
John Siracusa wrote: On 12/21/07 5:54 AM, Larry Wall wrote: To you and me, the fact that there are single quotes means there's something there to hide. But other people think the other way and see double quotes as indicating there's something to interpolate. I think PBP comes down on that side, but to me, single quotes are a little harder to see. And maybe there's some bias from seeing double quotes used non-interpolatively in American English. FWIW, my reasoning in this area is based on Laziness: single quotes mean I don't have to scan the string looking for interpolated stuff when reading code. Double quotes mean I do, and I'm annoyed at the waste of time when I scan and find nothing. Why didn't this guy just use singles here? It's (mildly) misleading. (There are obviously edge cases, even in Perl 5, but even naive adherence to this guideline is a good first approximation, with a second look only required in the rarest of cases.) Normally I'd go on the side of the reader and say yes, when writing code you should be picky about what quotes you use. But in this case I find that, on the writing side, I find it a common annoyance when I chuck a variable into a string and then only realize afterwards that it's not interpolating. On the reading side, I find visually scanning for $ in strings easy and I guess I assume everyone else does, too. -- We do what we must because we can. For the good of all of us, Except the ones who are dead. -- Jonathan Coulton, Still Alive
