Re: RFC 254 (v1) Class Collections: Provide the ability tooverloadclasses
Greg Williams wrote:
easy to see which one will be used. By providing a single location where
/ALL/ overloaded packages would go (VIRTUALZONE::${PACKAGE}), you limit
yourself in the amount a class (or class collection) may be extended.
VIRTUALZONE:: was an example; the virtual root could have any name, meaning
that any number of ISA hops could be required before resolution.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
"A taste so good that we stand behind every bottle and can."
Re: Draft RFC: new pragma: Cuse namespace
Graham Barr wrote: I would suggest that anyone want to contribute to this discussion should first read the thread about the addition of this pragma to perl5 in the perl5-porters archives http://www.xray.mpe.mpg.de/cgi-bin/w3glimpse/perl5-porters?query=use+namespace+pragmaerrors=0case=onmaxfiles=100maxlines=30 Graham. package chroot would be more powerful than use namespace. -- David Nicol 816.235.1187 [EMAIL PROTECTED] "After jotting these points down, we felt better." =head1 TITLE package chroot =head1 VERSION Maintainer: David Nicol [EMAIL PROTECTED] Date: 02 OCT 2000 Version: 1 Mailing List: [EMAIL PROTECTED] status: DEVELOPING Number: =head1 ABSTRACT Cpackage chroot is to Perl packages as Cchroot is to filesystem directories. This allows us a way to implement package name spaces hidden from each other, and also a way to hide some methods of a package which is installed within a "chroot jail." =head1 DESCRIPTION to rewrite perldoc -f package: =item package chroot =item package chroot NAMESPACE [, IMPORTKEY1 = IMPORTVAL1 [, IMPORTKEY2 = IMPORTVAL2 [, ...]]] Declares the namespace root of the compilation unit as being in the given namespace. The scope of the chrooting is from the declaration itself through the end of the enclosing block, file, or eval (the same as the Cmy() operator). All further Cpackage declarations within the chroot have the NAMESPACE prepended to their NAMESPACEs. Further Cpackage chroot declarations will nest. Within a chrooted environment, there is no way within the perl language to access a variable from outside the chrooted environment without an explicit accessor. =item IMPORT PAIR list Each item in the hash that follows the name of the new root package name space is an alias mapping. The key is the name in the new name space and the value is the name of the object in the old name space which is being imported with the new name. Variables, subroutined, and entire packages may be imported into the chroot, usually with their own names. Situations in which one would want to change the names of imported items are easy to imagine, for instace translations to other languages, or mocking up of emulation environments in which one would like to hide perl keywords that collide with keywords in the emulation. =item KEY,VALUE the key in the import pair is the name in the virtual space, the value is the name in the general space. This is so you can add an entire set of functionality, like CORE::, to the virtual space, and then take parts of it away. =item wild cards in import pairs a wild-card character * is defined in the import pair language. This allows all of the semantic descendents of a package to be imported together. For instance: package orig; # we are now in package orig:: package chroot C, # from here on in, all # globals will have C:: prepended # to their names CORE:: = CORE::, # but builtins will be visible 'A::*' = 'A::', # and everything in A:: and A::... 'B::' = 'E::',# all symbols E::... will be aliased to C::B::... '$frog' = '$cat'; # and $C::orig::frog will be $orig::cat but not @C::orig::frog or C::orig::frog '*main::frog' = '*main::frog';# and $C::main::frog will be $main::frog, and so will other whatzits associated with that name. $A::inA = 'inA';# sets $C::A::inA, AKA $A::inA $B::inB = 'inB';# sets $C::B::inB, BKB $E::inB $A::B::inAB = 'inAB'; # sets $C::A::B::inAB, AKA $A::B::inAB $B::A::inBA = 'inBA'; # sets $C::B::A::inBA only $cat = 'meow'; # sets $C::orig::cat $frog = 'meow'; # sets $C::orig::frog, AKA $orig::cat A reference within the jail to a symbol that has appeared in an imported package since the importing will refer to the same item as it would outside: if you want to import only the symbols which exist at import time you need to list them explicitly. =head1 CONFLICTS The requirement of an explicit namespace argument allows package chroot; to switch the current package to chroot:: like it does in Perl5. =head1 IMPLEMENTATION The root of the global symbol table becomes replacable. CCORE::package will need to recognize this as a special case. Wildcard imports could be implemented by adding code to the symbol resolver so that it knows that the package CA::B:: is "within" CA::. the implementation of Packages may need to be altered so package has a meaning greater than "what is by default prepended to otherwise unqualified variables" =head1 REFERENCES Discussion around RFC 254 on overloading classes
Re: RFC 348 (v2) Regex assertions in plain Perl code
Maintainer: Bart Lateur [EMAIL PROTECTED]
Date: 28 Sep 2000
Last Modified: 1 Oct 2000
Mailing List: [EMAIL PROTECTED]
Number: 348
Version: 2
Status: Frozen
[can't find a good quote]
It'd be somwhat useful, I think, if you could return somthing like \matched
to
let paren-catching of the ?{} thingy have somthing other then "". (Remember,
a ref is always true.)
For example, that would let you parse somthing inside a regex that
requires a complicated decision only once, with only common
regexish stuff outside the regex itself.
Of course, auto-deref is evil, but you can't just use the return value, or
you couldn't return things that aren't true, but match.
Replace the old implementation of (?{...}). Optionally, throw out all
the "localizing" code. Do not set any special variables.
It'd possibly be useful if the entire regex was considered to be a scope
WRT lexicals. This lets you pass data around the regex without ugly
action at a distance (not much of a distance, anyway) without having
special rollback code -- any rollback needed either normal to local,
or it's not our job. It feels like "transactional variables" may be a
Good Thing here.
If you don't remember transactional varables, the idea is that
if the block succeeds, the variables retain their values as set in the
block,
and if the block dies, they get reset to their initial condition. The
difference
here is that the "exception" raised is when the block gets rolled back.
This requires thinking about it after the fact, which might be harder.
(but no harder then the current situation.)
Basicly, it'd be like the current local situation, but with explicit naming,
fitting in with a wider feature (just slightly different).
The new feature should:
have a zero width impact on matching in the regex
I think it would be very nice to have some sort of way of making the
bit 'o code have nonzero length. You can do that now, but it Isn't Pretty:
(?{somecodeeatingstuff; $numate=3}).{$numate}
This is fairly straightforward, but it's modifing a global varable, which is
a
Bad Thing.
The question, of course, is how to implement such a thing. An "eat" builtin
would be pretty cool, but alas, too useful a name for other things. G
either succeed of fail, depending on the returned value as a boolean
scalar: true means it's ok to continue, false means a veto, causing the
regex to immediately backtrack.
And if you die, it will abort the regex?
Sorry to bring this stuff up after freeze -- I let my perl6 mail pile up too
much.
Oh, and assuming that I'm not making some stupid mistake, and with eat and
returning a ref, here's a killer app:
/([$matchingpairs])(.*?)(?{local $_=eat 1; $_ eq ${$matchingpairs[$1]}
\$1)/
It doesn't handle nesting thingies, but it's close.
(Assumes $matchingpairs{'('}=')'..., and $matchingpairs=join '', keys
%matchingpairs.)
-=- James Mastros
Re: RFC 303 (v1) Keep Cuse less, but make it work.
Alan Gutierrez [EMAIL PROTECTED] writes: On 27 Sep 2000, Piers Cawley wrote: Simon Cozens [EMAIL PROTECTED] writes: On Wed, Sep 27, 2000 at 03:49:10PM +0100, Tom Christiansen wrote: Don't change "use less" to "use optimize". We don't need to ruin the cuteness. "use less 'rolled_loops';" sounds really weird. We obviously need to introduce a synonymous Cuse fewer 'rolled_loops' for when we want to be grammatically correct. Or am I just being silly now? C use less 'recursion' sounds just find to me. The negation of C use less 'rolled_loops' , C use more 'unrolled_loops' , does not sound very weird at all. Weren't we planning on haveing a use more as an opposite of use less? If so, let cuteness prevail! And this opens the door to stuff like C no more 'rolled_loops' . I'm not entirely sure that that would be a good thing. -- Piers
Re: Expunge use English from Perl?
On Wed, 27 Sep 2000, Nathan Wiger wrote: Yeah, I've never liked the _ syntax, I've always thought it was weird (to say the least). I think grouping file tests would be much cleaner. As long as you are okay with having to restat for 'or' clauses. (There are work arounds, and supposedly 'this or that' is less common for file tests.) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Expunge use English from Perl?
On Mon, Oct 02, 2000 at 07:32:42AM -0400, Bryan C. Warnock wrote: On Wed, 27 Sep 2000, Nathan Wiger wrote: Yeah, I've never liked the _ syntax, I've always thought it was weird (to say the least). I think grouping file tests would be much cleaner. As long as you are okay with having to restat for 'or' clauses. (There are work arounds, and supposedly 'this or that' is less common for file tests.) A rather sweeping statement. ANDing makes more sense for the permissions checks, but ORing makes more sense for the type checks. For example, I can imagine -f $foo || -l $foo being a rather common idiom. -- Bryan C. Warnock ([EMAIL PROTECTED]) -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On Sun, Oct 01, 2000 at 06:34:12AM -, Perl6 RFC Librarian wrote: =head1 TITLE Perl should use XML for documentation instead of POD Wow. I'll just add my voice to the others. POD is more readable than XML. As Nathan Wiger said, just read the HTML vs the POD for the RFCs. But, why not suggest SDF instead of XML? SDF addresses most of POD's deficiencies whill still retaining readability. (I don't have a URL for SDF handy, but I'm sure a quick search on google.com would turn it up) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On Mon, 2 Oct 2000 08:29:09 -0500, Jonathan Scott Duff wrote: But, why not suggest SDF instead of XML? SDF addresses most of POD's deficiencies whill still retaining readability. (I don't have a URL for SDF handy, but I'm sure a quick search on google.com would turn it up) http://www.mincom.com/mtr/sdf/ It is based upon POD, which might help in lowering the entry threshold. -- Bart.
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On Mon, Oct 02, 2000 at 09:21:51AM -0700, Glenn Linderman wrote: Indeed, this is the key problem with human use of XML. HTML was originally simple enough to be human writable, its later, more powerful incarnations start losing that (but you can always use a subset for simple things, and XML never had human writable simplicity and never will. XML is intrinsically no more or less difficult to write than HTML. Comparing XML to HTML is pointless, however; they are not the same thing. Rather, compare XML to SGML, and specific XML DTDs (XHTML, for example) to HTML. XHTML is certainly no more difficult to write than plain HTML. The only real difference is that tags like hr become hr/ -- hardly a major difference. Indeed, I would consider the XHTML version to be a bit simpler to understand. - Damien
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On Mon, 2 Oct 2000 10:51:28 -0700, Damien Neil wrote: XML never had human writable simplicity and never will. XML is intrinsically no more or less difficult to write than HTML. The problem with XML is that it is so unforgiving; I think somebody already mentioned that. Improperly nested tags, or one character it doesn't recognize... and the parser says "nyet". -- Bart.
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
At 03:53 PM 10/2/00 +0200, Bart Lateur wrote: On Mon, 2 Oct 2000 08:29:09 -0500, Jonathan Scott Duff wrote: But, why not suggest SDF instead of XML? SDF addresses most of POD's deficiencies whill still retaining readability. (I don't have a URL for SDF handy, but I'm sure a quick search on google.com would turn it up) http://www.mincom.com/mtr/sdf/ It is based upon POD, which might help in lowering the entry threshold. Agreed. Let's not throw out the baby with the bathwater on this RFC; there's much to commend a proposal that allows enhanced documentation formatting within a script. I know that for 90% of the stuff we write, it's so short that simply-formatted comments and POD will do, but there's a whole world of software that uses things like cascading requirements documents, design and delivery reviews, white papers, etc, i.e., "large systems," of the type that are seldom written in Perl but which in principle could be. As long as we're designing something to stand the test of time for maybe five years or more, we can think a little bigger than usual. I don't use an IDE - unless you count Emacs - but the one feature that I've been panting for in my editor for a good 15 years that might induce me to do so would be the ability to independently collapse comment blocks of arbitrary size within my code to small labelled icons. Click on an icon, and it expands into comments explaining the code at hand; click again, and it collapses so you can see the code. Or it might pop up another window with a technical paper explaining the algorithm. People have suggested Emacs outline mode for this but it doesn't come close. Oops, got a bit carried away by the fantasy there. Anyway, a sufficiently extensible POD could allow the creation of such a thing. Granted, if your tool is a text editor that doesn't understand such comments, you might not like receiving one from someone unless they ran it through some kind of converter, but that shouldn't preclude the ability to construct the technology. How about just standardizing a syntax for embedding different languages and ensuring that perl can find where the block ends, he asked with some trepidation. Eg, ... perl ... =pod language=SDF boundary=VERYLONGSTRINGYOUGETTHEIDEA ... SDF ... VERYLONGSTRINGYOUGETTHEIDEA ... perl ... Not that this should stop us from improving POD as well... -- Peter Scott Pacific Systems Design Technologies
Re: RFC 357 (v1) Perl should use XML for documentation instead ofPOD
On 10/2/00 1:56 PM, Bart Lateur wrote: The problem with XML is that it is so unforgiving; I think somebody already mentioned that. Improperly nested tags, or one character it doesn't recognize... and the parser says "nyet". Kind of like Perl, huh... ;) (this is a feature, not a bug! :) -John
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
No-one ever did suggest adding « and » to the list of matched delimiters that q() etc support, did they? :-) I did. Does Unicode define bracket pairings for character sets? ducks $ grep ^Prop /usr/local/lib/perl5/5.6.0/unicode/Props.txt does not seem very helpful, but this may not be much of a proof. --tom
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
- Done right, it could be easier to write and maintain Strongly disagree. - Why make people learn pod, when everyone's learning XML? Because it is simple. It is supposed to be simple. It is not supposed to do what you want to do. In fact, it is suppose to NOT DO what you want to do. - Pod can be translated into XML and vice versa Then do that. - Standard elements could be defined and utilized with the same or greater ease than pod for build and configuration. /pod NameModule::Name/Name Version0.01/Version Synopsisshort description/Synopsis Description name=head1 long description/name section name=head2 heading/name list type="ordered" symbol="1" itemfoo/item /list Type in some text here... /section /Description AuthorEliott P. Squibb/Author MaintainerJoe Blogg/Author Bugsnone/Bugs CopyrightDistributed under same terms as Perl/Copyright section namedefine your own section/name blab here /section /pod That is an excellent description of why THIS IS COMPLETE MADNESS. --TOM
Re: RFC 327 (v2) C\v for Vertical Tab
On Sun, Oct 01, 2000 at 10:24:58AM +0200, Bart Lateur wrote: difficult feature, is a lot harder than this kind of simple, er, shit. Actually, when I was first programming Perl after coming from C I was tripped up by this very difference, and didn't quite understand why \v wasn't an escape. I forget what I was using it for. I certainly haven't used vertical tab in a long time, and even back then I was probably using it for an escape sequence or something similar rather than as a tab. Perhaps there's a good reason it wasn't included, perhaps someone reading this thread even knows what that reason is. Perhaps not, and it would actually be a good idea to include it in Perl 6 to avoid the kinds of (small) problems I had with it. Referring to this RFC as "shit" just because it's simple seems rather harse. If the big RFCs are like creating new tools in your toolkit, or radically changing the way they work, this one is like taking out an old tool and filing off a sharp point from the handle so it doesn't poke you next time you use it. I can't see that as a bad thing. -- Jacob Davies [EMAIL PROTECTED]
Re: 184 (v3): Perl should support an interactive mode
Very little discussion was generated by this RFC. Several people noted that perl -de 42 and the Perl shell psh already provide some of what the RFC requests; this is noted in the RFC. The RFC is not being withdrawn, since 2 other people expressed (mild) interest in it. I'd like to add that multiline shell capabilities would be *extremly* useful for the perldl shell (as already noted by the author) and pdl-porters emphatically support this RFC. If Python can do it Perl6 should be able to do it as well. In the very least multi-line sub definitions. Anything less would be disappointing. Christian
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On Mon, Oct 02, 2000 at 01:24:37PM -0600, Tom Christiansen wrote: XML is intrinsically no more or less difficult to write than HTML. Wrong. I beg your pardon? Comparing XML to HTML is pointless, however; they are not the same thing. Wrong. And you only say that because you will not like the answer. Go back to the posted example and count bytes of data versus bytes of meta data. Did you read what I wrote? XML is like SGML. It specifies a generic means of writing structured text; it says nothing about what that structure is. In particular, neither XML nor SGML specifies a particular set of tags. HTML is a particular SGML dialect; as such, it can only be compared to a specific XML dialect, not XML as a whole. exampleThis wordis/word XML./example It is also SGML. It is not, obviously, HTML. This is ttHTML/tt. This is ttXHTML/tt. No difference, really. You do see differences with things like the hr tag; SGML allows the DTD to define certain tags as being atomic, and XML does not. This means that hr must be written as hr/ in XHTML. Now, if you want to compare an XML DTD like DocBook to HTML, you have a point. DocBook contains whole heaping piles of complexity. I'd certainly rather write HTML than DocBook by hand. I guarantee you that you will drive people away with this crap. What? I don't think people should be writing either XML or HTML as the source documentation format. I said that, quite clearly. - Damien
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
Jonathan Scott Duff [EMAIL PROTECTED] writes: I'll just add my voice to the others. POD is more readable than XML. Don't forget: more _writable_ as well. -- Johan
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On 10/2/00 4:44 PM, John Barnette wrote: * Advanced concepts that POD cannot contain that the XML junkies might want to be used can be embedded. (=for XML) Yeah, but then you get =for HTML, =for XML, =for 3DHOLOGRAM, whatever. No one does that because no one wants to make 50 versions of the table they have in their docs, one for each document type they happen to be able to think of at the moment. The do it in ASCII art an are done with it because they realize the futility of making 5 different versions. POD is supposed to be the common format that can be transformed into other representations. Instead, you have to add the different representations yourself if you do anything remotely complex. People are looking for POD alternatives because doing complex things in POD is so hard and/or annoying. And those that do add neat little =for HTML bits so their docs look nice in pod2html or whatever are basically pigeonholing themselves in the land of HTML. What everyone wants here is some standard format that is rich enough to be converted to anything: a format that can handle complex items like tables and hyperlinks and embedded images and all that good stuff. "It can be done" in POD, but there are so many varying ways to do it that it creates a barrier to users. So people stick to Plain Old POD, sans fancy =for business, 90% of the time. XML is probably not the answer, but I really do think POD needs to evolve along with the rest of Perl. -John
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On Mon, 2 Oct 2000 13:54:47 -0400, Tad McClellan wrote: Improperly nested tags, or one character it doesn't recognize... and the parser says "nyet". I read that as "the machine will tell me when I messed up". I'd rather have a machine tell me than have to figure it out myself. I think I claim some of the Good Laziness there :-) That's not my experience with XML::Parser. It gives some weird error message, mentions a line number and a column number that doesn't even exist... and that's it. It's not very helpful. You usually don't even get any output so you can see where and how you messed up. It's the same Good Laziness that tells me it's no good. -- Bart.
RE: RFC 357 (v1) Perl should use XML for documentation instead of POD
From: Myers, Dirk [mailto:[EMAIL PROTECTED]] Maybe I'm reading too much into the comment, but I thought the big deal was that the example given was not only verbose, but wouldn't parse correctly: (from the section you elided:) AuthorEliott P. Squibb/Author MaintainerJoe Blogg/Author Whoops. We need a /Maintainer tag there. Yes, and it'd be patently obvious to the parser where the problem is and easier to generate a specific and meaningful warnings to boot. Not to mention if you use a gui editor incorporated color coding, it'd be easier to read and see errors. Emacs cPerl doesn't handle pod very well... anyone know why that is? True. And the fact that the example wasn't written properly isn't a conclusive proof that it's not easy to do. But it isn't exactly an encouraging sign, either. Can you see the problematic extra space here? No... I didn't think so... =pod =head1 Header =cut
Re: RFC 357 (v1) Perl should use XML for documentation instead ofPOD
XML, on the other hand, uses as the escaping mechanism, helping a reader sort-out deeply-nested escapings. ... POD has a good advantage in that it's design allows for it to embed well into code. If documentation is to be alongside code, a direction to consider is to have the Perl program be an XML document itself, with the code inside of it, between designated tags. This would allow for the entire Perl program/document to be rendered in a unified manner, using one tool, and conforming to one meta-language, XML. By making a Perl program an XML document, the programmer is forced to read the XML. It should be noted that XML isn't supposed to be read by a person - it is meant to be read by a computer. The W3C document "XML in 10 points" states this as point three. From http://www.w3.org/XML/1999/XML-in-10-points : XML files are text files, as I said above, but even less than HTML are they meant to be read by humans. They are text files, because that allows experts (such as programmers) to more easily debug applications, and in emergencies, they can use a simple text editor to fix a broken XML file. .greg -- Greg Williams| If you wish to live a life free from sorrow, Cnation | think of what is going to happen as if it had [EMAIL PROTECTED] | already happened.
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On Mon, Oct 02, 2000 at 10:59:46PM +0200, Bart Lateur wrote:
On Mon, 2 Oct 2000 13:54:47 -0400, Tad McClellan wrote:
Improperly nested tags, or one character it
doesn't recognize... and the parser says "nyet".
I read that as "the machine will tell me when I messed up".
I'd rather have a machine tell me than have to figure it
out myself. I think I claim some of the Good Laziness there :-)
That's not my experience with XML::Parser. It gives some weird error
message, mentions a line number and a column number that doesn't even
exist... and that's it. It's not very helpful. You usually don't even
get any output so you can see where and how you messed up.
It's the same Good Laziness that tells me it's no good.
That is a deficiency in XML::Parser (a tool) not with XML.
I find that nsgmls (with an XMLified SGML Declaration) does
a good job. I always check XML data with nsgmls first.
(nsgmls is an SGML parser, not a XML parser, but I've never
come across bad XML that it lets by...
)
XML::Parser gives bad messages, so XML is bad.
The Blue Screen Of Death is bad, so computers are bad?
[ Puhleeeze don't think that I am defending XML over POD. I am
firmly in the POD camp. So many others are in that camp, that
I just haven't added my aolMe too!/aol ('til now :-)
]
--
Tad McClellan SGML consulting
[EMAIL PROTECTED] Perl programming
Fort Worth, Texas
Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)
At 03:15 PM 10/2/00 -0700, Nathan Wiger wrote: Dan Sugalski wrote: Well, yeah, it'll sort of have to if we allow user-defined types. If you do: my Dog $spot : male; then the Dog package needs to be able to fetch the attributes. I've no idea how that'd look--perhaps an attributes() function, a method in UNIVERSAL, or something like that. There's two ways I've proposed in different RFC's. The first one utilizes a more general framework; the second one depends on Ctie being used. A UNIVERSAL:: method wouldn't work because you've got to get attributes from arrays and hashes as well. Maybe I'm just being dense, but why shouldn't arrays and hashes inherit attributes from UNIVERSAL? tie()ing an array is really just like being able to call object methods on it distinct from its members, no? So arrays and hashes could be objects too. Hmm, am I saying that I should be able to write @array-method()? There again, maybe it's just this head cold I've got. -- Peter Scott Pacific Systems Design Technologies
Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)
There's two ways I've proposed in different RFC's. The first one utilizes a more general framework; the second one depends on Ctie being used. A UNIVERSAL:: method wouldn't work because you've got to get attributes from arrays and hashes as well. Maybe I'm just being dense, but why shouldn't arrays and hashes inherit attributes from UNIVERSAL? tie()ing an array is really just like being able to call object methods on it distinct from its members, no? So arrays and hashes could be objects too. Hmm, am I saying that I should be able to write @array-method()? I think under tie this is *exactly* what we should be aiming for. I think this is awesome. However, making it a UNIVERSAL method also dictates that this: my SomeType @a :someattr; *must* be either: 1. a builtin type 2. tied To get its attributes back out. I'm not sure this is going to always be true. In particular, what if SomeType was like "int", and you were just trying to assert that each individual element was going to be SomeType? If these problems were resolved, then I must admit to having a perverse softspot for being able to say: my packed @bits :long; %attrs = @bits-attributes; I dunno...I like the way that looks for some reason... ;-) -Nate
Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)
At 03:32 PM 10/2/00 -0700, Nathan Wiger wrote: There's two ways I've proposed in different RFC's. The first one utilizes a more general framework; the second one depends on Ctie being used. A UNIVERSAL:: method wouldn't work because you've got to get attributes from arrays and hashes as well. Maybe I'm just being dense, but why shouldn't arrays and hashes inherit attributes from UNIVERSAL? tie()ing an array is really just like being able to call object methods on it distinct from its members, no? So arrays and hashes could be objects too. Hmm, am I saying that I should be able to write @array-method()? I think under tie this is *exactly* what we should be aiming for. I think this is awesome. However, making it a UNIVERSAL method also dictates that this: my SomeType @a :someattr; *must* be either: 1. a builtin type 2. tied To get its attributes back out. I'm not sure this is going to always be true. In particular, what if SomeType was like "int", and you were just trying to assert that each individual element was going to be SomeType? Then the int package would Do The Right Thing, of course. :) Just because they're provided types doesn't mean we won't be using the standard methods on them. (Though granted we may push a lot of the twiddly details into the main perl compile since we'll already know them--no reason to be unnecessarily dynamic) And even if the int/float/str/bigint/bigfloat types aren't really modules, there's no reason the core can't fake it to look like they are... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)
At 03:23 PM 10/2/00 -0700, Peter Scott wrote: At 03:15 PM 10/2/00 -0700, Nathan Wiger wrote: Dan Sugalski wrote: Well, yeah, it'll sort of have to if we allow user-defined types. If you do: my Dog $spot : male; then the Dog package needs to be able to fetch the attributes. I've no idea how that'd look--perhaps an attributes() function, a method in UNIVERSAL, or something like that. There's two ways I've proposed in different RFC's. The first one utilizes a more general framework; the second one depends on Ctie being used. A UNIVERSAL:: method wouldn't work because you've got to get attributes from arrays and hashes as well. Maybe I'm just being dense, but why shouldn't arrays and hashes inherit attributes from UNIVERSAL? tie()ing an array is really just like being able to call object methods on it distinct from its members, no? So arrays and hashes could be objects too. Hmm, am I saying that I should be able to write @array-method()? Sure, why not? I'd love to be able to throw things into the HASH package now and do %foo-something. Not often, mind, but occasionally... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)
At 03:32 PM 10/2/00 -0700, Nathan Wiger wrote: Maybe I'm just being dense, but why shouldn't arrays and hashes inherit attributes from UNIVERSAL? tie()ing an array is really just like being able to call object methods on it distinct from its members, no? So arrays and hashes could be objects too. Hmm, am I saying that I should be able to write @array-method()? I think under tie this is *exactly* what we should be aiming for. I think this is awesome. RFC 82 would probably prefer that this have a component-wise interpretation :-) However, making it a UNIVERSAL method also dictates that this: my SomeType @a :someattr; *must* be either: 1. a builtin type 2. tied To get its attributes back out. I'm not sure this is going to always be true. It must be my sinuses. I don't get that at all. Firstly, @a can't be tied before that statement since you only just declared it; the tie would have to follow. Secondly, if the declaration declares @a as belonging to class SomeType, then unless SomeType.pm is perverse enough to override the attributes() method, why won't @a-attributes go through to UNIVERSAL? Whether or not SomeType is builtin? Or are we talking apples and oranges and the above declaration is intended to declare that any *member* of @a is of SomeType, never mind the array itself? In particular, what if SomeType was like "int", and you were just trying to assert that each individual element was going to be SomeType? If these problems were resolved, then I must admit to having a perverse softspot for being able to say: my packed @bits :long; %attrs = @bits-attributes; I dunno...I like the way that looks for some reason... ;-) Me too. -- Peter Scott Pacific Systems Design Technologies
Re: 0, true or false? (was: PERL6STORM #0052)
Bart Lateur wrote: Bitwise and, or and xor do distinguish strings from numbers, and return entirely different kinds of results. Why can't anything else? Absolutely. There is such a thing as Too Much Convenience. I think BOOL as a context or an accessor method should be separate from STRING and NUMBER so that if you know, you can suggest which behavior you want out of a particular scalar variable, or stick with the misguidable default. -- David Nicol 816.235.1187 [EMAIL PROTECTED] "After jotting these points down, we felt better."
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
On Mon, Oct 02, 2000 at 03:36:20PM -0500, Garrett Goebel wrote: From: Tom Christiansen [mailto:[EMAIL PROTECTED]] - Done right, it could be easier to write and maintain Strongly disagree. Ok, you disagree. There are differing opinions here. Can we agree to disagree? No. Agreeing to disagree about this is like agreeign to implement Perl with three parts C, two parts Eiffel, two parts Python and one part Objective C. TMTOWTDI can't always be invoked simply because this project is named Perl. Or must all people who believe XML is easier to write and maintain leave the room? There are huge cultural, technical and practical limitations for Perl to adopt XML as a documentation syntax, or code all docs in =xml...=cut blocks. If you want to use XML, Latex, Texinfo or raw *roff for your docs, then by all means do so. Understand that Perl can't be made to magically ignore embedded Texinfo, and Perl contributors realistically can't be made to understand/patch/correct multiple markup formats. This is why we invented POD. This is why we use POD. Horror of horrors: why not support both? Long live: TMTOWTDI. If XML documentation fails to thrive, cut it from Perl 6.1. XML docs *have* failed to thrive among those who document Perl. They have failed to thrive among that group for over two years, especially since all that's missing is someone thinking about a definitive POD-XML conversion. (Sorry, I'd chip in, but I'm a little busy this week.) That is an excellent description of why THIS IS COMPLETE MADNESS. Being able to parse for well-definedness, DTD validation, and schema constraints are postive things. And none of them *require* XML. There's no reason why POD can't be well-defined, validated and schema correct. Z.
Re: RFC 339 (v1) caller-eval BLOCK
Greg Williams wrote:
Interesting! I have a few questions (meandering thoughts) though g
The example in the RFC gives:
sub A{
my $A = shift;
return with;
};
$context1 = A(3);
print "$context1"; # something like CONTEXT(0XF0GD0G)
print "$A" with $context1; # prints 3
with $context1{print "$A"}; # same thing
This implies that A is now something akin to a closure, correct?
I'm not sure how perl5 differnetiates btn closures and non-closures,
I thought it just defered certain aspects of scope destruction.
That is to say, the meaning of Cmy $A becomes changed by the
presence of Creturn with; so that $A is something in between a
lexical scoped to A and a lexical scoped around A ({ my $A; sub A
{} }). $A is held in existence by the presence of the context
object. Presumably $A would 'go out of scope' and be destroyed at
the same time as the associated context object? This worries me, but
I admit it's neat ;)
Yes, thus the warning about memory leaks.
What is more worrying to me is this: with a Cno scope; pragma, you
can only go up /your/ scope. Consider this:
package Nasty;
my $context;
{
package Unsuspecting_Package;
$context = with;
}
use integer with $context;
Spooky action at a distance to be sure! Also, integer (and others)
is a compile time issue. Using Cno scope can be easily (it would
appear) implemented for compile-time since it's merely another
pragma. On the other hand, Cwith strikes me as more of a run-time
beast. (at this point, I'm not sure if I have any idea of what I'm
talking about, so excuse me if this has digressed into rambling :)
I agree. If we were to allow run-time changing of aspects of basic reality
(I think we should, if we can, and we can) then every time we do it
a flag gets set telling Perl to throw out its cache of jump tables and reread
the instructions. Or the cache just gets thrown out. What if
use integer
and similar pragmata not only change aspects of eval() but also throw out all
the previous work. In that context.
Or maybe it would have no effect at all:
use real;
sub pi_teration{
# one iteration of some pi-finidng algo
...
};
use integer;
# did I or did I not just hork my pi_iteration routine?
So I like the idea of Cwith, but am not sure it is compeltely
suitable for invoking pragmata such as integer.
it depends on what is and waht is not "within" a context. That is
a question I would like to defer.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
"After jotting these points down, we felt better."
Re: Conversion of undef() to string user overridable for easy debugging
Jarkko Hietaniemi wrote:
This reminds me of a related but rather opposite desire I have had
more than once: a quotish context that would be otherwise like q() but
with some minimal extra typing I could mark a scalar or an array to be
expanded as in qq(). For example doubling the $ and @? $$foo, @@bar?
This comes in handy when you are generating big blocks of code on the
fly but only tiny parts of it needs to be interpolated. Unfortunately
the margin of my monitor is not enough to describe this wonderful idea
in a form of a RFC.
$qqdString =~ s/\[(\w+)\]/defined($vars{$1})?$vars{$1}:"[$1]"/ge;
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
"After jotting these points down, we felt better."
Re: Conversion of undef() to string user overridable for easy debugging
On Mon, Oct 02, 2000 at 09:17:31PM -0500, David L. Nicol wrote:
Jarkko Hietaniemi wrote:
This reminds me of a related but rather opposite desire I have had
more than once: a quotish context that would be otherwise like q() but
with some minimal extra typing I could mark a scalar or an array to be
expanded as in qq(). For example doubling the $ and @? $$foo, @@bar?
This comes in handy when you are generating big blocks of code on the
fly but only tiny parts of it needs to be interpolated. Unfortunately
the margin of my monitor is not enough to describe this wonderful idea
in a form of a RFC.
$qqdString =~ s/\[(\w+)\]/defined($vars{$1})?$vars{$1}:"[$1]"/ge;
I'm sorry but that didn't quite make my heart leap with joy :-)
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: 0, true or false? (was: PERL6STORM #0052)
"David L. Nicol" wrote: Bart Lateur wrote: Bitwise and, or and xor do distinguish strings from numbers, and return entirely different kinds of results. Why can't anything else? Absolutely. There is such a thing as Too Much Convenience. I think BOOL as a context or an accessor method should be separate from STRING and NUMBER so that if you know, you can suggest which behavior you want out of a particular scalar variable, or stick with the misguidable default. See RFC 159 - BOOLEAN, STRING, and NUMBER are the three main methods. -Nate
Re: RFC 344 (v2) Elements of @_ should be read-only by default
Perl6 RFC Librarian [EMAIL PROTECTED] writes: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Elements of @_ should be read-only by default =head1 VERSION Maintainer: John Tobey [EMAIL PROTECTED] Date: 28 Sep 2000 Last Modified: 1 Oct 2000 Mailing List: [EMAIL PROTECTED] Number: 344 Version: 2 Status: Frozen =head1 ABSTRACT Unprototyped subs should not be allowed to modify their callers' data simply by assigning to elements of the arg array. =head1 COMMENTS ON FREEZE This RFC generated no discussion in 3 days I'd just like to put in an 'ick' vote on this one. I might come up with something a little longer and more reasoned later, but I'm supposed to be writing shopping basket code. -- Piers
