Re: Smart match isn't on Bool
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 that ($anything ~~ foo()) just throws away $anything. No; only if foo() returns a Bool. How do you define that? Any type which is compatible with Bool? What happens if, in a bold and innovative stroke, some future revision of Perl 6 decides that Type is compatible with Bool? Who wins in $a ~~ Int? If my function returns 1 but False will 1 ~~ func() match? I guess what I'm really asking, here, is do we use the first rule in the smart-match table from S03 or is there some other priority system at work? Do we consider only exact type matches and shunt everything else into Any or do we call X.does(type)? On a related note, I re-read S03 a bit and I've come to the conclusion that the ~~ op (not the implicit smart match of given/when) should produce a warning when its RHS is Bool (assuming we resolve what is Bool means, above). There's just no good reason to confuse the issue that way, and the Bool behavior of smart-matching is really just there to support given/when. Beyond that, once we start getting into deeper warnings on semantic mistakes, it's likely that it will make sense to warn at run-time if when is asked to work on a boolean value which isn't the result of some form of comparison. Again, it's just confusing for no benefit. If we add the above warnings and the ones already listed in S03, then I think I'll be fine with it. I understand why we want when .foo == .bar and I can't think of a good way to replace it, so I'll buy that it's worth making so many other obvious uses deprecated. -- Aaron Sherman Email or GTalk: a...@ajs.com http://www.ajs.com/~ajs
How are unrecognized options to built-in pod block types treated?
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 block form here is that the abbreviated block form doesn't take config options, and my question is about those. S26 doesn't mention the config option :image in connection with '=head1'. (As it shouldn't, I'm using it for my own nefarious purposes.) I went looking for whether this is allowed or not. Is this allowed? S26 only tells me this about config options: Pod predefines a small number of standard configuration options that can be applied uniformly to any built-in block type. To me, predefines could mean either we made these for you; use only those or we made these for you; go wild and invent your own too if you wish. It also has this to say about block types: Typenames that are entirely lowercase (for example: C=begin head1) or entirely uppercase (for example: C=begin SYNOPSIS) are reserved. But it's clear from the context of that sentence that this only pertains to blocks. There's no indication that this goes for the config options as well. Unless I missed the place, S26 simply doesn't specify whether unrecognized config options to built-in blocks should cause the parser to blow up or not. Should it? I guess one could make this question really interesting by throwing in issues of forward-compatibility and such. Should we expect to be able to parse Pod from the future, i.e. using versions of the Perl 6 spec with more Pod options defined for the built-in blocks? I'm not savvy enough to attack that last question, but apart from that, I think allowing/ignoring unrecognized config options seems reasonable. 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 identifiers. That sounds sane to me as well; the only question is whether that much structure is needed for config options. // Carl
Re: How are unrecognized options to built-in pod block types treated?
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 identifiers. That sounds sane to me as well; the only question is whether that much structure is needed for config options. I did not consider this issue when designing S26, but in considering it now, I think Carl's suggestion is entirely sensible and in line with what I intended. 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 least a warning when they are parsed. Mixed-case config options should be freely available to users and the parser should simply accept them without complaint and include them in the internal data structure it builds, whereupon they will be available to user-defined Pod extensions. Damian
Re: How are unrecognized options to built-in pod block types treated?
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 encountered), and let the custom ones live in the namespace of mixed-case identifiers. That sounds sane to me as well; the only question is whether that much structure is needed for config options. I did not consider this issue when designing S26, but in considering it now, I think Carl's suggestion is entirely sensible and in line with what I intended. 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 least a warning when they are parsed. Mixed-case config options should be freely available to users and the parser should simply accept them without complaint and include them in the internal data structure it builds, whereupon they will be available to user-defined Pod extensions. Damian 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 strange beasts, and i don't know the answer. ~jerry
Re: Natural Language and Perl 6
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 an old, dead laptop. I've been thinking about reviving that, but haven't been able to find it yet. Maybe I'll just start over. It was quite nice for working with Lojban text. See, not so off-topic after all. :)
Re: How are unrecognized options to built-in pod block types treated?
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 or not. Is this allowed?
S26 only tells me this about config options:
Pod predefines a small number of standard configuration options that
can be applied uniformly to any built-in block type.
To me, predefines could mean either we made these for you; use only
those or we made these for you; go wild and invent your own too if
you wish.
I see no reason for it to not simply store any additional values away for
potential future use.
It also has this to say about block types:
Typenames that are entirely lowercase (for example: C=begin head1)
or entirely uppercase (for example: C=begin SYNOPSIS) are reserved.
But it's clear from the context of that sentence that this only
pertains to blocks. There's no indication that this goes for the
config options as well.
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.
THAT in turn means that we need a way to add config options in a point
release in order to push out new features in reasonable time, and that means
they need their own namespace.
I'd suggest:
=for head1 :reserved('image=foo.jpg')
which is identical to:
=for head1 :image('foo.jpg')
except for the fact that any unrecognized option of the first form is an
error and any unrecognized option of the second form is allowed. That way,
new features can be added to :reserved and migrated over time to stand-alone
options after being listed in the release notes for a couple of cycles.
--
Aaron Sherman
Email or GTalk: a...@ajs.com
http://www.ajs.com/~ajs
Re: How are unrecognized options to built-in pod block types treated?
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 least a warning when they are parsed. Mixed-case config options should be freely available to users and the parser should simply accept them without complaint and include them in the internal data structure it builds, whereupon they will be available to user-defined Pod extensions. 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 strange beasts, and i don't know the answer. There's a simple solution to that. Just say that names consisting entirely of either ASCII-range uppercase letters or ASCII-range lowercase letters are reserved, and that names having either both of those or any of those plus non-ASCII letters are not reserved. The only way I see this being a problem is if we forsee that we might want to have official names going out of the ASCII repertoire, which I would recommend we don't. -- Darren Duncan
Re: How are unrecognized options to built-in pod block types treated?
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 sensible people will avoid those namespaces anyway, so they might as well be reserved...which then enables us to warn any not-so-sensible people that their choice of an all-lower- or all-upper-case option name is brittle and likely to end in tears. BTW, I also like Darren's suggestion to restrict the reserved space for standard typenames and option names to the ASCII range. Dåmîäñ
Re: How are unrecognized options to built-in pod block types treated?
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 level of namespace. Perl just reserves a namespace for itself for official names, and the other namespaces are available for use by others. For brevity, the namespace qualifier may be omitted when referring to the Perl-reserved namespace, and so any names that appear unqualified are assumed to be there by default. This is somewhat analogous to the main:: namespace for Perl code. 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. If POD declares that it is written to a particular version of the POD spec, then any unqualified names are taken as reserved ones iff that version of the POD spec included them, and they are taken as user-defined otherwise. I really think that's the way to go. It can also be documented that the official POD spec will likely just use all-uppercase or all-lowercase ASCII words, but that isn't a promise and rather is a convention; there may be a good reason to change later. Explicit versioning is your friend. Can I get some support for this? -- Darren Duncan
Re: How are unrecognized options to built-in pod block types treated?
-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 languages are strange beasts, and i don't know the answer. Just say that names consisting entirely of either ASCII-range uppercase letters or ASCII-range lowercase letters are reserved, and that names having either both of those or any of those plus non-ASCII letters are not reserved. The only way I see this being a problem is if we forsee that we might want to have official names going out of the ASCII repertoire, which I would recommend we don't. For the first, you're also excluding scripts that lack the notion of case: Hebrew and Arabic, and all of the ideograms, etc. As to the latter, Perl 6 already has «» and ASCII equivalent ; I would expect similar would be possible and supported in this context. (Yes, I know, I'm not helping. Only thing that occurs to me is something like x-foobie:.) - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxaNEIACgkQIn7hlCsL25VyawCeJDcFIYePVqVXs/ICYOXPTdCM 4EsAnAl4FWfDNVXBrBEyVkcRLRdrUq+X =9TYE -END PGP SIGNATURE-
Re: How are unrecognized options to built-in pod block types treated?
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 strange beasts, and i don't know the answer. Just say that names consisting entirely of either ASCII-range uppercase letters or ASCII-range lowercase letters are reserved, and that names having either both of those or any of those plus non-ASCII letters are not reserved. The only way I see this being a problem is if we forsee that we might want to have official names going out of the ASCII repertoire, which I would recommend we don't. For the first, you're also excluding scripts that lack the notion of case: Hebrew and Arabic, and all of the ideograms, etc. As to the latter, Perl 6 already has «» and ASCII equivalent ; I would expect similar would be possible and supported in this context. (Yes, I know, I'm not helping. Only thing that occurs to me is something like x-foobie:.) Read what I said again. I was proposing that the namespace comprised of names matching a pattern like this: /^ [A..Z]+ | [a..z]+ $/ ... be reserved for official use and the complementary namespace be available for users to define names in. So users can use anything with non-ASCII characters plus those with mixed-case ASCII. So users aren't excluded from using Hebrew or Arabic characters due to what I said, but only that official names wouldn't use them. -- Darren Duncan
Re: How are unrecognized options to built-in pod block types treated?
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 Pod do anything you want by extending or replacing the grammar (just like [any other part of] Perl 6). So an unrecognized directive should be an error like an unrecognized method or rule, but presumably you'd be using whatever modules are necessary to recognize them. On 2010-08-04, at 8:05 pm, Damian Conway wrote: I think it's a dreadful prospect to allow people to write documentation that they will have to rewrite when the Pod spec gets updated. Or, alternatively, to require all Pod parsers to be infinitely backwards compatible across all versions. :-( But nobody will have to rewrite anything, any more than you have to rewrite all your old code. Nor create a mega-parser that combines all possible versions. Just continue to use the original modules it was designed for, which, with proper versioning, will happen automatically. Isn't handling such versioning worries one of the best features of P6? (After all, docs aren't special to Perl — it's all just code that it will parse and process any way you tell it to.) Darren: Explicit versioning is your friend. Yes, always! -David
