C<< >> vs C<< >> vs C<< x >>

Ugh.

So we all know that there's this syntax for formatting codes (n=E9s "interio=
r
sequences") like C<< x >>.
And that tokenizes as three tokens:
  "C<< ",   open-C code
  "x",      content
  " >>"     close-code matching the C open-code


And this is explicated by what I wrote in perlpodspec where I say that such
a code...

* starts with a capital letter (just US-ASCII [A-Z]) followed by two or
more "<"'s, one or more whitespace characters,

* any number of characters

* one or more whitespace characters, and ending with the first matching
sequence of two or more ">"'s, where the number of ">"'s equals the number
of "<"'s in the opening of this formatting code.


But I do not remember putting /immense/ thought into the question of
whether the content should consist of "any" (0+) number of characters or
"some" (1+) number of characters.
And now I'm beginning to wonder about two problems that occur when a C<< >>
code is empty (corresponding to an XML "<C></C>").

Notably, those problems are:
  How should C<<  >> tokenize?
And:
  How should C<< >> tokenize?

I see two possibilities:

* a C start-code
* empty-string content
* an end-code matching the C start-code

or:

* a C start-code (consisting of the C<< and all the subsequent whitespace)
* a literal ">>"



I'm tempted to just stipulate that codes with the syntax like C<< ... >>
must not be empty, which pretty much allows the latter tokenziation in both
cases.

First, there's the completely obvious argument that C<< ... >> codes were
devised specifically to handle the cases where the intended content
contained a literal ">", as on C<< $foo->bar >>, so using them with
no-content is daffy.
Secondly, empty codes in general (whether C<< ... >> or C<...>) in Pod are
of extremely dubious value -- I can't imagine why one would want a B<> or a
I<> or a C<> or a F<> or an S<>, much less why one would want to use B<< >>
syntax for them.
That's even beside all the implementational hassles that can lurk in trying
to make a tokenizer deal with C<< >> and/or C<<  >> as if either/both were
C<< Z<> >>!


--
Sean M. Burke    sburke@cpan.org    http://www.spinn.net/~sburke/
0
sburke (114)
1/27/2002 1:52:19 AM
perl.pod-people 528 articles. 0 followers. Follow

2 Replies
1283 Views

Similar Articles

[PageSpeed] 58

On Sat, Jan 26, 2002 at 06:52:19PM -0700, Sean M. Burke wrote:
> * starts with a capital letter (just US-ASCII [A-Z]) followed by two or
> more "<"'s, one or more whitespace characters,

When this particular syntax was first suggested by Larry (and later accepted by p5p) it was for 2 _or_ _more_ '<' characters, followed by /\s+/, and ending with whitespace and an equivalent number of '> as there were opening '<'.

The reason I recall being suggested for this ... is the moment that the syntax becomes valid, it also becomes a prospective 'literal', so by allowing it to be 2-or-more, it readily resolved that problem without much extra parsing effort.

> Notably, those problems are:
>   How should C<<  >> tokenize?
> And:
>   How should C<< >> tokenize?
> 
> I see two possibilities:
> 
> * a C start-code
> * empty-string content
> * an end-code matching the C start-code

I would have assumed it would parse a the beginning (start-code) being /<<\s+/ and the ending being /\s+>>/. I would assume the number of '<' must equal the number of '>', but I wouldn't assume the need for matching the exact number/content of whitespace characters for either delimited, and I would assume the "content" was an empty string, and that if spaces were intended they should use S<  >

But thats just me :)
-- 
Brad Appleton <bradapp@enteract.com>  http://www.bradapp.net/
  "And miles to go before I sleep." -- Robert Frost
0
bradapp
1/27/2002 3:20:51 AM
On Sat, Jan 26, 2002 at 06:52:19PM -0700, Sean M. Burke wrote:

> And now I'm beginning to wonder about two problems that occur when a C<< >>
> code is empty (corresponding to an XML "<C></C>").
> 
> Notably, those problems are:
>   How should C<<  >> tokenize?
> And:
>   How should C<< >> tokenize?

[latter tokenization being:]

> * a C start-code (consisting of the C<< and all the subsequent whitespace)
> * a literal ">>"
> 
> 
> 
> I'm tempted to just stipulate that codes with the syntax like C<< ... >>
> must not be empty, which pretty much allows the latter tokenziation in both
> cases.
> 
> First, there's the completely obvious argument that C<< ... >> codes were
> devised specifically to handle the cases where the intended content
> contained a literal ">", as on C<< $foo->bar >>, so using them with
> no-content is daffy.

I think I'd be quite happy with C<< >> being illegal if it contains only
whitespace. If someone wants to write C<> or C< > then they can use single
<>, surely?

Nicholas Clark
-- 
ENOCHOCOLATE http://www.ccl4.org/~nick/CV.html
0
nick
1/27/2002 10:37:32 AM
Reply:

Similar Artilces:

[PATCH] Fix POD: C<...->...> => C<< ...-> ... >>
--=-0nPiZliXhb80VRfJ/8qX Content-Type: text/plain Content-Transfer-Encoding: 7bit See the attached patch, it fixes some POD which gets rendered wrong by newer POD rendering tools. Thanks, Frank --=-0nPiZliXhb80VRfJ/8qX Content-Disposition: attachment; filename="0001-Fix-POD-C-.-.-C.patch" Content-Type: text/x-patch; name="0001-Fix-POD-C-.-.-C.patch"; charset="UTF-8" Content-Transfer-Encoding: 7bit From ed46d8dd56e57d51347cb0a7a6397687ee15a950 Mon Sep 17 00:00:00 2001 From: Frank Wiegand <frank.wiegand@gmail.com> Date: Thu, 19 Nov 2009 1...

[PATCH] correctly handle C<< >> and C<<< >>> in diagnostics
This is just a quick hack; ideally someone would make it use an actual pod parser. --- perl/lib/diagnostics.pm.orig 2003-12-30 15:48:47.000000000 -0800 +++ perl/lib/diagnostics.pm 2004-05-25 01:54:31.735904000 -0700 @@ -314,10 +314,10 @@ sub noop { return $_[0] } # spensive for a noop sub bold { my $str =$_[0]; $str =~ s/(.)/$1\b$1/g; return $str; } sub italic { my $str = $_[0]; $str =~ s/(.)/_\b$1/g; return $str; } - s/[BC]<(.*?)>/bold($1)/ges; + s/C<<< (.*?) >>>|C<< (.*?) >>|[BC]<(.*?)>/bold($+)/ges; ...

RFC 199 (v2) Short-circuiting C<grep>, C<map>, and C<reduce> with C<last>
(or "Allowing built-in functions to use loop blocks") Reply-To: perl6-language@perl.org This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Short-circuiting C<grep>, C<map>, and C<reduce> with C<last> (or "Allowing built-in functions to use loop blocks") =head1 VERSION Maintainer: Garrett Goebel <garrett@scriptpro.com> Date: 6 Sep 2000 Last Modified: 7 Sep 2000 Mailing List: perl6-language@perl.org Number: 199 Version: 2 Status: Developing =head1 ABSTRACT Allow buil...

r31680 -[S32/Temporal] Added to Date: "There are also C<week>, C<week-year>, C<week-number>, C<weekday-of-month>, and C<day-of-year> methods, which work just like their DateTime equivalents."
Author: Kodi Date: 2010-07-14 16:35:46 +0200 (Wed, 14 Jul 2010) New Revision: 31680 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Added to Date: "There are also C<week>, C<week-year>, C<week-number>, C<weekday-of-month>, and C<day-of-year> methods, which work just like their DateTime equivalents." Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod =================================================================== --- docs/Perl6/Spec/S32-setting-library/Temporal.pod 2010-07-14 14:35:21 UTC (rev 316...

Should C<grep> and C<reverse> work in C<Any> ?
Do C<grep> and C<reverse> act like the C<join> method, in that they work for C<Any> object and not just objects of type C<List>? In other words,, should C< $x.grep(...) > work even if $x isn't normally a list type? Pm --- On Sun, 29/6/08, Patrick R. Michaud <pmichaud@pobox.com> wrote: > Do C<grep> and C<reverse> act like the > C<join> method, in that > they work for C<Any> object and not just objects of > type C<List>? >=20 > In other words,, should C< $x.grep(...) > work e...

>>>> Heads up <<<<
I just got a warning from Norton that "PamelaSetup-Basic.exe" has a virus in it. The name is "VirusBurst" Luckily, I did not install this software and Norton's quarantined it so I could delte it, which I have done. Symantec has not completed analysis of this particular piece of garbage but it did catch the sig. If you have installed Pamela, you may be in trouble. Duffy wrote: > I just got a warning from Norton that "PamelaSetup-Basic.exe" has a virus > in it. The name is "VirusBurst" > > Luckily, I did not install...

C<croak> in XS does C<die> not C<croak>
I just saw a question on comp.lang.perl.modules where the error message: Bad arg length for Socket::unpack_sockaddr_in, [...] at C:/Perl/lib/Socket.pm line 295. understandably confused a user who had simply passed an invalid argument to C<sockaddr_in>. This is exactly the situation that C<Carp::croak> is meant to avoid so it is unfortunate in this case that, in XS code, C<croak> acts like C<die> and not like C<Carp::croak>. Anyone recall past discussions on whether XS C<croak> should be able to skip up the call stack until it finds a...

VB <<<>>> C#
it will be usefull to have a good Vb C# | C# Vb translatorangiras I'll ask around and see if I can find out if we're planning to offer translation. In the meantime, you can find a number of them on the web, and you can also look into the DTE (our automation model) Code Model - you may be able to use it to do some interesting forms of translation. -ScottThis posting is provided "AS IS" with no warranties, and confers no rights. I have never heard about this code model ! thanksangiras they say Namespace: EnvDTE I cannot find it is it Microsofz.Win32 ?angiras The EnvDTE DL...

X<> vs. X<< >>
perlpodspec gives "two syntaxes" for formatting codes. There's X<content> and X<< content >>. In the "two or more angle brackets" form, the whitespace immediately following << and preceding >> are not renderable. That's fine, but I'm confused as to why that isn't just the universal case. Is it just a backcompat issue that someone might have been relying on B< foo > having spaces at either end? I've been pondering how to simplify how some things are explained, and that's one place where I think the sp...

>>>> ROOT Exploit in SAMBA <<<<<<
"A flaw has been detected in the Samba main smbd code which could allow an external attacker to remotely and anonymously gain Super User (root) privileges on a server running a Samba server. This flaw exists in previous versions of Samba from 2.0.x to 2.2.7a inclusive. This is a serious problem and all sites should either upgrade to Samba 2.2.8 immediately or prohibit access to TCP ports 139 and 445." http://us3.samba.org/samba/samba.html Binaries are available from Samba for RedHat, and some other distributions. So far as I can tell, the RedHat update mirrors I norm...

RFC 151 (v1) Merge C<$!>, C<$^E>, and C<$@>
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Merge C<$!>, C<$^E>, and C<$@> =head1 VERSION Maintainer: Peter Scott <Peter@PSDT.com> Date: 24 Aug 2000 Version: 1 Mailing List: perl6-language@perl.org Number: 151 =head1 ABSTRACT The distinction between the C<$!>, C<$^E>, and C<$@> variables is no longer worth trading for the benefits to be gained from merging them together. =head1 DESCRIPTION The C<$!> variable made excellent sense in Perl 4 as a repre...

>>>> BUY RAM <<<<
.. ~~~*@@@*~~~ ================================================== ================================================== ENTER HERE: >>> http://web-for-you.cn/about/buy-ram <<< ================================================== ================================================== .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ...

>>>> CAPITALS GAMES <<<<
.. ~~~!!!~~~ ================================================== ================================================== CLICK HERE TO ENTER: >>> http://web-paradise.cn/3/capitals-games <<< ================================================== ================================================== .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ....

RFC 199 (v1) Short-circuiting C<grep> and C<map> with C<last>
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Short-circuiting C<grep> and C<map> with C<last> =head1 VERSION Maintainer: Garrett Goebel <garrett@scriptpro.com> Date: 6 Sep 2000 Mailing List: perl6-language@perl.org Version: 1 Number: 199 Status: Developing =head1 ABSTRACT Allow functions like C<grep> and C<map> with implicit loop blocks to be short circuited with C<last>. =head1 DESCRIPTION It'd be nice if one could use C<grep> to find out if a value is hel...

Web resources about - C<< >> vs C<< >> vs C<< x >> - perl.pod-people

Resources last updated: 11/30/2015 8:01:09 AM