On Tue, Aug 3, 2010 at 3:30 PM, David Green david.gr...@telus.net wrote:
On 2010-08-02, at 2:35 pm, TSa (Thomas Sandlaß) wrote:
On Monday, 2. August 2010 20:02:40 Mark J. Reed wrote:
[...] it's at least surprising. I'd expect (anything ~~ True) to be
synonymous with ?(anything)
Note also
Straight to an example:
=for head1 :imageulteriorepicure-328651980.jpg
Steaming hot Cfor loops
As far as parsing goes, that's valid Perl 6 Pod. You're perhaps more
used to seeing it as '=head1', but S26 asserts the equivalence of
these two forms. The reason I'm using the paragraph
Carl proposed:
The other path that seems reasonable to me would be to use the same
naming scheme as for the block types, i.e. reserve all-upper and
all-lower forms (and die if an unrecognized one of this form is
encountered), and let the custom ones live in the namespace of
mixed-case
On Wed, Aug 4, 2010 at 15:56, Damian Conway dam...@conway.org wrote:
Carl proposed:
The other path that seems reasonable to me would be to use the same
naming scheme as for the block types, i.e. reserve all-upper and
all-lower forms (and die if an unrecognized one of this form is
Not long ago, yary proclaimed...
This is getting more and more off topic, but if you want some lojban
pasers, start at
http://www.lojban.org/tiki/tiki-index.php?page=Dictionaries,+Glossers+and+parsers
I have a translation of the Lojban grammar in Perl 6 rules sitting
around somewhere, possibly
On Wed, Aug 4, 2010 at 6:00 PM, Carl Mäsak cma...@gmail.com wrote:
Straight to an example:
=for head1 :imageulteriorepicure-328651980.jpg
Steaming hot Cfor loops
Interesting that this comes up right as I was composing my help email ;)
I went looking for whether this is allowed
jerry gay wrote:
On Wed, Aug 4, 2010 at 15:56, Damian Conway dam...@conway.org wrote:
Specifically, I think it would be easiest to be consistent and say
that all purely lowercase and all purely uppercase config option names
are reserved, and that unrecognized reserved config options generate
at
Aaron wrote:
I dislike reserved in this context, but understand why the namespace has
to be shared. For config options, I'd say anything should go, but people
inventing their own config options should be aware that across N release
cycles, new options may be introduced.
...which means that
There's also potentially another simple solution, which in some ways is
superior, and means we can avoid the whole thing about upper/lowercase being
significant, that case thing honestly seems like a cludge.
Use namespaces.
In the generic sense, we could say that all names are in at least one
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/4/10 21:26 , Darren Duncan wrote:
jerry gay wrote:
are there codepoints in unicode that may be either upper-case or
lower-case, depending on the charset? if so, then there's ambiguity
here, depending on the user's locale. i suspect not, but
Brandon S Allbery KF8NH wrote:
On 8/4/10 21:26 , Darren Duncan wrote:
jerry gay wrote:
are there codepoints in unicode that may be either upper-case or
lower-case, depending on the charset? if so, then there's ambiguity
here, depending on the user's locale. i suspect not, but languages
are
On 2010-08-04, at 7:43 pm, Darren Duncan wrote:
A parallel solution would be that POD can declare a version, similarly to how
Perl code can declare a Perl version, whose spec it is expected to be
interpreted according to.
I thought that was more or less how it worked anyway. You can make
12 matches
Mail list logo
