Re: Angle quotes and pointy brackets
Larry Wall writes:
The basic problem with «...» is that most of its uses were turning out
to be more useful that the corresponding ... and I think I'm
ready to propose a Great Angle Bracket Renaming.
I very much like your proposal. (Though whether you were actually ready
to propose it yet is obviously something only you can decide ...)
* We steal angles away from iterators.
That means that Apocalypse 2 can be updated by _removing_ an existing
[Update] block!
Most of the complaints about non-Ascii characters in Perl relate to the
guillemets. With your proposal they are relegated to much less-commonly
constructs, and people who really don't like them can mostly avoid
having to go anywhere near them.
* We get ... as the qw// shorthand where a term is expected.
I like that. When Apocalypse 2 first came out I switched to using
angles as Cqw delimiters most of the time, such as:
use Some::Module qwthis that;
in an attempt to get used to them having that meaning, and so there's
less of a jump to Perl 6. Over 3 years later I can report that they
work very well for this.
* Since we already stole angles from iterators, «$fh» is not
how you make iterators iterate. Instead we use $fh.fetch (or
whatever) in scalar context, and $fh.fetch or @$fh or $fh[]
or *$fh in list context.
Good. That is the single thing I find hardest to teach to beginners in
Perl 5; output has an explicit Cprint statement, but the input doesn't
appear to be anywhere in the code -- there's just some brackets in a
Cwhile loop, and it doesn't occur to people that brackets might have
the effect of reading from a file.
However, does anything in this proposal conflict with keeping C as
the special-case token for reading from standard-input-or-the-files-
named-on-the-command-line? That way people who like that super-short
idiom get to keep it, in:
for { ... }
while anybody who's gone to the bother of typing out a named stream has
to put a little more effort in to specify that iteration is required.
* That means that, roughly, we have this proportion:
'...' : ... :: ... : «...»
That makes good sense. It also means that people are free to continue
to ignore the variant they don't like (such as the many people who
prefer to use C quotes in Perl 5 even when no interpolation is
required), which to some extent reduces the validity of any carping.
Bearing in mind how much more can now be done with out unicode (or ugly
C variants) and I think this proposal should result in a nett
carping reduction (especially by people who don't following this mailing
list closely and therefore haven't been getting used to the previous
scheme -- I'm sure it'd be received better by those people who are yet
to meet any Perl 6 at all).
Smylers
Re: Angle quotes and pointy brackets
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Larry Wall) wrote: Here's the proposal. First the bad news: * We accept that the C operator requires whitespace around it, and be prepared to be burned in effigy occasionally. I wouldn't go that far, although when I inevitably get burned by it, I might let slip some intemperate comparisons regarding whitespace and programming in Python... =) * That means that, roughly, we have this proportion: '...' : ... :: ... : «...» I wasn't sure at first, but I think you just sold me. (I'm a sucker for parallels.) * The :w splitting happens after interpolation. So « foo $bar @baz » can end up with lots of words, while « foo $bar @baz » is guaranteed to end up with three words. Now I'm a bit lost. I would've expected the quotes () inside a different kind of quote («) to be taken literally (just as in 'foo $bar @baz' or qw/foo $bar @baz/). I'm not even sure what those double-quotation marks are doing -- preventing $bar from being interpolated as a variable, or preventing the interpolated value from being white-split? (Of course, to keep the pattern going, I'd propose for no interpolation, for interpolation (but not subsequent splitting), and introduce for going whole-hog and interpolating *with* subsequent splitting. (Not that I'm saying I'd actually ever use triple quotes, I just wanted to propose them for the parallelism.)) * A rule like ident now captures, while «ws» or ws doesn't. I think I really like that last outcome. Capturing should be the default. And the low profile of «ws» makes it look like an oh by the way. I don't think I like that as much as you do. I'm not sure I *dislike* it either... but I would be tempted to say that the double guillemets should do twice as much (identify AND capture). That might be simply because I'm not used to it, though. Either way, I know I really like being able to drop the parentheses when capturing like that. Overall, I think the new proposal is an improvement. -David «foo» Green
Iteration Again (was «Re: Angle quotes and pointy brackets»)
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Brent 'Dax' Royal-Gordon) wrote:
I'm going to pull a Larry and think out
loud for a minute here. Note that I speak authoritatively here,
Noted. Or not. =)
Treating it like an array is wrong.
On the other hand, what if a filehandle *is* an array? What if you
can access it randomly and non-destructively?
I like this line of thought -- sure, arrays and iterators are
different, but they're also similar, so they ought to look similar in
at least some ways. We already think of files in a somewhat-array-
like manner (Gimme line 42 of this file) rather than mere iterators
(Get the first 41 lines of this file, throw them away, and then gimme
the next one), so why shouldn't Perl reflect that? Keeping the easy
things trivial and all...
An iterator can also be quite unlike an array (for instance a pipe,
where you can't jump back to the beginning, even inefficiently), but
I think those differences apply at a slightly higher level,
conceptually. (Or they would if we weren't forced by the language to
think of them differently at the lower level.) After all, if you
know you're dealing with a pipe, it would probably never even occur
to you to try accessing it randomly; on the other hand, if you don't
know whether your object is an array or a file or a pipe to begin
with, you're already in trouble.
But .shift looks a bit awkward. I suggest a name change for .shift
and .unshift, so that we have:
push, pop
pull, put
Hm, I like that, the parallelisms with the number of letters, and the
way they all begin with P. Plus the meanings make sense (you pull
something towards you -- that's the front end -- but when something
pops off, it goes flying away from you -- that's the back).
So now we have:
my $fh=open foo.txt;
say $fh.pull;
for $fh.pullall {
I'm not crazy about pullall. If the idea is we want to slurp up
the file right now, can't we use our flattening splatter? (for
[EMAIL PROTECTED] ...)
And what about iterators in general? Well, if we can do it to
filehandles, why not all iterators? An iterator is simply a lazy
array copy that isn't accessed randomly;
Or maybe a lazy array is just an iterator (with some extra abilities
added on). But I'm all for taking advantage of the commonalities.
-David which is related to another kind of laziness Green
Re: Angle quotes and pointy brackets
David Green writes: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Larry Wall) wrote: * The :w splitting happens after interpolation. So « foo $bar @baz » can end up with lots of words, while « foo $bar @baz » is guaranteed to end up with three words. Now I'm a bit lost. I would've expected the quotes () inside a different kind of quote («) to be taken literally (just as in 'foo $bar @baz' or qw/foo $bar @baz/). I'm not even sure what those double-quotation marks are doing -- preventing $bar from being interpolated as a variable, or preventing the interpolated value from being white-split? Look back at how Larry defined the guillemets: * That frees up «...» for Something Else. * That something else is the requested variant of qw// that allows interpolation and quoting of arguments in a shell-like manner. So the double-quotes in there are shell-like, though I guess if you don't have a Unix background that doesn't mean much to you. (Post again if that's the case -- I have to leave for work now, but I'm sure somebody here will be able to explain.) Smylers
Re: Angle quotes and pointy brackets
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Smylers) wrote: David Green writes: I'm not even sure what those double-quotation marks are doing -- [...] Look back at how Larry defined the guillemets: [...] So the double-quotes in there are shell-like, though I guess if you don't have a Unix background that doesn't mean much to you. Ah, of course. I read that straight in one eye and out the other. =) -David getting carried away with parallelogies that aren't quite there, but I like the new definition anyway Green
Re: Angle quotes and pointy brackets
Larry Wall wrote:
I thought so.
: I don't think I've ever used a hash slice in my life. Is there something
: wrong with me?
No, a lot of people are naturally monoindexous.
I like that word.
: * The :w splitting happens after interpolation. So
:
: « foo $bar @baz »
:
: can end up with lots of words, while
:
: « foo $bar @baz »
:
: is guaranteed to end up with three words.
:
: See the comment about 'fabulouser' above and add another 'and
: fabulouser' to the end.
I neglected to mention that the smart quoter should also recognize
pair notation and handle it.
I've been trying to get my brain round that, but I can't quite figure
out what you mean. Pair notation is, as I understand it, when you get
key = value
to construct a pair. Assuming that's me remembering correctly, then
where does the smart quoter have to deal with pair notation? Are you
considering allowing something like:
« key1 = flop key2 = floop »
Which would be
hash(key1 = flop, key2 = floop);
or am I completely off my rocker? I hope I am, because that's kind of
ugly. The only other thing I can think of is if you're just talking
about *implementing* infix:=, in which case just ignore the above
because of course the autoquoter needs to recognise its left-hand-side.
As an aside, is it possible for us to define our own autoquoting
operators? I assume it will be, but I'm feeling insecure and need
reassurance.
I neglected to mention that we also naturally get both of:
circumfix:« »
circumfix:« »
in addition to
circumfix:{'',''}
circumfix:{'«','»'}
Have to be careful with
circumfix:«{ }»
though, since {...} interpolates these days.
Yes, that would be fun... almost worth throwing out a compiler warning
for that, especially if we've still got use warnings. Something like
Warning: «{ }» creates empty list
or even
Warning: circumfix:«{ }» creates empty operator
that one could be an error in fact.
or if you're feeling really nasty
Syntax error
Because I'm sure it should be wrong to create empty circumfix operators.
Or am I too prescriptive? My inner Haskell programmer is showing through.
Re: Angle quotes and pointy brackets
Matthew Walton skribis 2004-12-01 9:55 (+):
Yes, that would be fun... almost worth throwing out a compiler warning
for that, especially if we've still got use warnings. Something like
Warning: «{ }» creates empty list
It should generate a warning similar to the warning of interpolating an
undefined value, but with s/undefined variable/empty list/.
Because I'm sure it should be wrong to create empty circumfix operators.
You have to admit that zero width circumfix operators would be VERY NEAT.
Juerd
Re: Angle quotes and pointy brackets
Juerd wrote:
Matthew Walton skribis 2004-12-01 9:55 (+):
Yes, that would be fun... almost worth throwing out a compiler warning
for that, especially if we've still got use warnings. Something like
Warning: «{ }» creates empty list
It should generate a warning similar to the warning of interpolating an
undefined value, but with s/undefined variable/empty list/.
Yes, that would make sense.
Because I'm sure it should be wrong to create empty circumfix operators.
You have to admit that zero width circumfix operators would be VERY NEAT.
Well that depends... are you intending to write programs, or drive the
world insane?
Re: Angle quotes and pointy brackets
Matthew Walton skribis 2004-12-01 10:11 (+): Well that depends... are you intending to write programs, or drive the world insane? Yes. Juerd
Re: Angle quotes and pointy brackets
Matthew Walton writes: Pair notation is, as I understand it, when you get key = value That can now also be written as: :keyvalue or, where value is 1, simply as: :key I suspect it was this form that Larry was referring to. Smylers
Re: qq:i
John Macdonald wrote:
The problem with interpolate if you can or leave it alone for
later is that when later comes around you're in a quandry.
Is the string $var that is in the final result there because
it was $var in the original and couldn't be interpolated,
or was it a $foo that had its value of $var injected into
its place?
The maybe do it now, finish up later what wasn't done the
first round approach runs the risk of double interpolation.
(Or single interpolation, or non-interpolation, whichever
it happened to roll on the dice.) If you're Randal Schwartz
discovering a
s/Old Macdonald/$had a $farm/eieio
accidental feature, that can be useful; but for mere portals,
it is just a bug waiting to surface.
Maybe this should be the default behavior.
my $nameRight = name;
my $nameWrong = other name;
print $nameRight != $name_wrong\n;
name != $name_wrong
I wonder where my mistake is?
This looks like a decent win for PEBKAC errors. Maybe this should go on
by default if the I need help flag is turned on.
OTOH, I don't have much use for the original proposal because I also
want to be able to defer interpolation of variables that DO exist, like $!.
I like the idea of defining a secondary interpolation character, or
perhaps a secondary escape character.
my $name = defined now, but it will change later;
my $output_text = EOF:esc('`');
$template_header
`$name
$template_footer
EOF
=Austin
Re: Angle quotes and pointy brackets
On Wed, 01 Dec 2004 07:41:18 GMT, Smylers [EMAIL PROTECTED] wrote:
John Siracusa writes:
Call me crazy, but at this point I'm prone to stick with what I've done in
Perl 5 for years:
$var{'key1'}{'key2'}[3]{'key3'}
In which case do that, since it'll still work in Perl 6.
[...]
So life is better for people who like writing hash subscripts as you do.
But for those who like autoquoting, there's now a different syntax, one
that doesn't interfere with the above syntax at all. You don't have to
use it if you don't want to, and everybody's happy!
Even if I don't use it, I'd like it not to be ugly and awkward (or, heaven
forbid, non-ASCII) because I'm likely to have to read and edit it a lot
(just as I have to deal with a lot $of{this} these days...sigh)
Although I like the single/double angle swap in most places, I'm definitely
not a fan of the fragile fish chain syntax for hash keys.
-John
Re: qq:i
Jim,
qq:i {} is just like qq{} except that when it interpolates variables,
those which are undefined are preserved literally.
I think surprise might be a problem. E.g.
my $index = 0;
eval qq:i {
my @array = A .. Z;
sub example {
for my $index (0 .. $#array) {
#stuff
}
}
}
Common variable names like $i, $index, $element etc might end up being
replaced by mistake in the qq:i {}. Can't see it being acceptable in
strict code.
Interesting idea except for the flaw.
Jonathan Paton
Re: qq:i
On Wed, 1 Dec 2004 00:22:25 +, Jonathan Paton [EMAIL PROTECTED] wrote:
Jim,
qq:i {} is just like qq{} except that when it interpolates variables,
those which are undefined are preserved literally.
Interesting idea except for the flaw.
I think we almost have something like this already. Looking at the
updated Synopsis 2, I think you can use closure interpolation with
single quotes like this:
my $name = 'vars';
my $code = q:c[ my @{$name} = ($a, $b, $c); ];
# prints my @vars = ($a, $b, $c); ;
say $code;
The problem is that you also need {}'s for subroutines and other
things. But the underlying problem is that using another character to
interpolate doesn't get you anywhere because then you can't use that
in your code.
So... maybe we can pass a parameter saying what we want to use to interpolate?
my $name = 'add';
my $code = q:c«[
sub «$name» ($left, $right) {
return $left + $right;
}
];
# prints
# sub add ($left, $right) {
# return $left + $right;
# }
#
Where you could whatever you wanted instead of «».
--
matt diephouse
http://matt.diephouse.com
Re: qq:i
On Wed, Dec 01, 2004 at 11:41:37AM -0500, Matt Diephouse wrote:
: So... maybe we can pass a parameter saying what we want to use to interpolate?
:
: my $name = 'add';
: my $code = q:c«[
: sub «$name» ($left, $right) {
: return $left + $right;
:}
: ];
: # prints
: # sub add ($left, $right) {
: # return $left + $right;
: # }
: #
:
: Where you could whatever you wanted instead of «».
Or maybe we just stick with what we already allow:
my $name = 'add';
my $code = q[
sub \qq[$name] ($left, $right) {
return $left + $right;
}
];
After all, that's why we put \q interpolation into '' in the first place.
Larry
Re: qq:i
On Wed, 1 Dec 2004 08:56:49 -0800, Larry Wall [EMAIL PROTECTED] wrote:
Or maybe we just stick with what we already allow:
my $name = 'add';
my $code = q[
sub \qq[$name] ($left, $right) {
return $left + $right;
}
];
After all, that's why we put \q interpolation into '' in the first place.
I missed that. Thanks.
--
matt diephouse
http://matt.diephouse.com
Re: Angle quotes and pointy brackets
On Wed, Dec 01, 2004 at 09:55:32AM +, Matthew Walton wrote: : I neglected to mention that the smart quoter should also recognize : pair notation and handle it. : : I've been trying to get my brain round that, but I can't quite figure : out what you mean. Pair notation is, as I understand it, when you get : : key = value : : to construct a pair. Assuming that's me remembering correctly, then : where does the smart quoter have to deal with pair notation? Are you : considering allowing something like: : : « key1 = flop key2 = floop » : : Which would be : : hash(key1 = flop, key2 = floop); : : or am I completely off my rocker? I hope I am, because that's kind of : ugly. Yes, that's the sort of thing I mean. I actually want it for enum defs: my Scalar enum hex « :zero(0) one two three four five six seven eight nine :tena eleven twelve thirteen fourteen fifteen »; : As an aside, is it possible for us to define our own autoquoting : operators? I assume it will be, but I'm feeling insecure and need : reassurance. You can replace the whole darn grammar if you like, so it's certainly possible. I don't think we'll go out of our way to make it easy though. Probably requires a lookahead on the identifier rule to see if the next thing happens to be a = workalike. Alternately, you have to do syntax tree munging with an infix macro, since by the time you see an infix macro its left argument is already parsed. Larry
Re: qq:i
Larry Wall writes:
Or maybe we just stick with what we already allow:
my $name = 'add';
my $code = q[
sub \qq[$name] ($left, $right) {
return $left + $right;
}
];
After all, that's why we put \q interpolation into '' in the first place.
Ahh yes. Silly me, thinking there was something without a nice
solution. This is Perl!
Luke
