Re: Backslashes
Larry Wall wrote :
>
> Well, if anything, we're going the other direction, and enriching what
> you can do with a backslash in single quotes slightly. But it ought
> to be pretty easy to define your own hyperquotes. We might also have
> options on quotes like we do on regexen. Then we could tell it what
> to interpolate and what not to:
>
> q:bsahfmc/\t $foo @array %hash &func() $obj.method() { closure }/
>
> 'Course, that's pretty klunky.
And that doesn't seem very flexible.
If you're going to specify your quoting rules for your own q//
operators, I think that this should be specified as hints to the very
perl parser.
A simple example : in C, you could choose to interpolate
only the array @foo, or the array element @foo[42].
> So maybe we have something like an
> immediate subroutine definition:
>
> my sub qa is quote("bsahfmc") {...}
> qa/\t $foo @array %hash &func() $obj.method() { closure }/
>
> Then you could say something like:
>
> my sub q is quote("") {...}
> 'You think I' _ q{'} _ 'm knit-picking!'
>
> to get the behavior you want.
That sounds a bit like my Sub::Quotelike module.
Re: Backslashes
On Tue, 2002-05-21 at 13:22, Buddha Buck wrote:
> At 01:10 PM 05-21-2002 -0400, Aaron Sherman wrote:
> >The quesiton here is that C<\\'>, which means something different in
> >your recommendation than it means in Perl5, but still does the same
> >thing
>
> And the other question is how to get a string that ends in a \?
>
> $hiddendirectory = q{C:\$ecret$tuff\mp3\don't tell the mpaa\};
>
> >Is there any gotcha, here? I'm not sure, but it's tickling my brain in
> >an odd way, and I keep wanting to say that it breaks down somewhere
>
> Is the above the gotcha you've been looking for?
Yes, thank you. I knew there was a fairly standard problem with that, I
just could not remember what it was.
Re: Backslashes
On 05/21/02 Aaron Sherman wrote:
> On Tue, 2002-05-21 at 12:57, Michael G Schwern wrote:
>
> > Here's an easier one: backslash followed by the delimiter is that thing.
> > Everything else is literal.
> >
> > print 'c:\it\'s\easier\to\write\win32\paths\this\way';
> > print q{this is ok { and so is \} } C:\this };
>
> I desire you print your statement above. Would it be:
>
> print 'print \'c:\it\\'s\easier\to\write...\';';
>
> The quesiton here is that C<\\'>, which means something different in
> your recommendation than it means in Perl5, but still does the same
> thing
C# has verbatim strings where backslash doesn't quote the next char:
Write (@"c:\it's\easier\to\write\win32\paths\this\way");
and
Write (@"Write (@""c:\it's\easier\to\write\win32\paths\this\way"")");
(note you need to use two double quotes: basically in verbatim strings
" escapes, but it can be only followed by itself).
string s = @"blah
continued blah";
works, too.
With a parser tweak perl could use @" and @' to introduce such strings
(they are not already taken as special vars): I don't see big quirks
with that notation.
lupus
--
-
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
Re: Backslashes
At 01:10 PM 05-21-2002 -0400, Aaron Sherman wrote:
>On Tue, 2002-05-21 at 12:57, Michael G Schwern wrote:
>
> > Here's an easier one: backslash followed by the delimiter is that thing.
> > Everything else is literal.
> >
> > print 'c:\it\'s\easier\to\write\win32\paths\this\way';
> > print q{this is ok { and so is \} } C:\this };
>
>I desire you print your statement above. Would it be:
>
> print 'print \'c:\it\\'s\easier\to\write...\';';
>
>The quesiton here is that C<\\'>, which means something different in
>your recommendation than it means in Perl5, but still does the same
>thing
And the other question is how to get a string that ends in a \?
$hiddendirectory = q{C:\$ecret$tuff\mp3\don't tell the mpaa\};
>Is there any gotcha, here? I'm not sure, but it's tickling my brain in
>an odd way, and I keep wanting to say that it breaks down somewhere
Is the above the gotcha you've been looking for?
Re: Backslashes
On Tue, 2002-05-21 at 12:57, Michael G Schwern wrote:
> Here's an easier one: backslash followed by the delimiter is that thing.
> Everything else is literal.
>
> print 'c:\it\'s\easier\to\write\win32\paths\this\way';
> print q{this is ok { and so is \} } C:\this };
I desire you print your statement above. Would it be:
print 'print \'c:\it\\'s\easier\to\write...\';';
The quesiton here is that C<\\'>, which means something different in
your recommendation than it means in Perl5, but still does the same
thing
Is there any gotcha, here? I'm not sure, but it's tickling my brain in
an odd way, and I keep wanting to say that it breaks down somewhere
Re: Accessor methods ?
On 5/21/02 9:56 AM, "Aaron Sherman" <[EMAIL PROTECTED]> claimed: > I guess the run-time checks will be required, and inlining of small > chunks of code will never really be all that useful (as you cannot rip > open that scope and optimize the whole context). I think that a number of these issues of inlining methods were considered by p5p about two years ago, when Doub MacEachern submitted a patch that optimized Perl 5 method calls. Simon wrote about it here: http://www.perl.com/lpt/a/2000/06/dougpatch.html Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Backslashes
On Tue, May 21, 2002 at 11:03:42AM +0100, Nicholas Clark wrote:
> I believe that the correct rule for single quote context in perl should have
> been that backslash followed by anything is that thing.
That leaves Win32 users stuck in the same rut as now:
print 'c:\\it\'s\\going\\to\\be\\hard\\to\\read\\win32\\paths';
Read on.
> It's easier than the current one - backslash followed by backslash or the
> opening or closing delimiter is that thing, else it's backslash followed by
> that thing. Because to parse the contents of a string with this rule, you
> have to know what delimiter is.
Here's an easier one: backslash followed by the delimiter is that thing.
Everything else is literal.
print 'c:\it\'s\easier\to\write\win32\paths\this\way';
print q{this is ok { and so is \} } C:\this };
there's no need to backwack a lone backslash in single-quote context since
there's no ambiguity. It's trivial for the parser to figure out what the
terminating delimiter, in fact, it *has* to know else it can't terminate the
string! So there's no extra work for the parser.
The rule can be stated here clearly: Backwack the delimiter.
--
This sig file temporarily out of order.
Re: Accessor methods ?
On Mon, 2002-05-20 at 00:27, Larry Wall wrote:
> Aaron Sherman writes:
> : > Alternately, I think we should be able to mark subs as 'final' or 'inline'
> : > to indicate our guarantee that they won't be modified. Of course, it'll
> : > conflict with auto memoizing or auto currying modules that'd want to
> : > override it, but that's their fault. :)
> :
> : Yes, I suggested "inline" or "const" I can't imagine that we would
> : want to do without this, regardless of what we call it. Otherwise,
> : auto-accessors will always be slower than using the variable. Would
> : everyone agree that this property should default to being set for
> : auto-accessors?
>
> No, that would undo the whole point of making them accessors in the
> first place.
Think of this like a constant variable. In Perl5, we can do:
use constant foo=>1;
use constant foo=>2;
and foo will have the value 2, but you cannot change the value of foo
during run-time. That's all I'm saying for accessors. This way, when I
define
class argh {
my $.foo;
}
I get
method foo() is rw($newfoo) is inline { ... }
but, in another module, there's nothing to stop you from:
method argh::foo() { die "No, you don't!" }
because all that matters is that AFTER perl sees you call C<$obj.foo>,
it never changes.
Of course, this all goes out the window if inlining happens at
compile-time, since libraries will no longer be able to override
auto-accessors later on.
> : In this model, you only ever inline at load time ***OR*** when the
> : compiler is attempting to produce a self-contained byte-code executable
> : (e.g. one which has all of the modules in it), in which case it executes
> : that part of the load time process early. If you like, call this a
> : sub-stage of load time, which I shall dub "link time". Link time can
> : only happen once per program, so it must happen when we actually know
> : what all of the program components are.
>
> It seems like an assumption that link time can only happen once. An
> incremental linker might feel like it can relink any time it feels like
> it. Some very useful programs never completely know what their
> components are.
Agreed, and I would be remiss if I didn't mention that all good
intentions go out the window the moment someone does:
sub mumble() is inline { ... }
eval 'use stuff;mumble()';
Now, we could have the case where mumble has been redefined, or the case
where mumble is still the old inlinable thing, but inlineables that it
calls have been redefined.
Ick, *shudder*.
I guess the run-time checks will be required, and inlining of small
chunks of code will never really be all that useful (as you cannot rip
open that scope and optimize the whole context).
