Re: RFC 51 (v2) Angle brackets should accept filenames a
Chaim Frenkel wrote:
What does
$foo = "filename";# 1
$bar = "another";
$gaz = "filename; # 2
^ add " here
Does #2 get the second line or the first?
$gaz contains the second line. Otherwise this:
while ('filename'){print;};
won't work. This gets a little hairy, I admit.
Can the contain a function?
Of course. Stick any old list there.
Your example seems to indicate that
it can. But if it is hard for me to parse visually, I'm not sure
how easy it would be for the parser.
This is an implemenation detail. On the other hand, I was hoping that
it would be easy for a human parser. Perhaps it only takes some getting
used to. Like the first time I saw something like:
for ($foo){
/pattern/ next;
print join ' ', /pattern_with_groups/;
};
To my eye angle brackets signify input.
Jon
--
Knowledge is that which remains when what is
learned is forgotten. - Mr. King
Re: RFC 14 (v2) Modify open() to support FileObjects and
Graham Barr [EMAIL PROTECTED] writes: On Wed, Aug 09, 2000 at 11:41:42AM -0500, Jonathan Scott Duff wrote: How about this? open '/etc/passwd'; # file OK open '/usr/local/bin/'; # directory (note the trailing '/') Portability, not all platforms use / Allowing URI/URL syntax can perhaps dodge the "portability" issue URLs use / so if user thinks URL they think /. -- Nick Ing-Simmons
Re: RFC 14 (v2) Modify open() to support FileObjects and
In message [EMAIL PROTECTED] Graham Barr [EMAIL PROTECTED] wrote: On Wed, Aug 09, 2000 at 11:41:42AM -0500, Jonathan Scott Duff wrote: open 'ftp://ftp.perl.org/'; # ftp What user/password does it use Whatever you put in the URL with anonymous as default. open 'http://www.yahoo.com/'; # http will it support cookies, authentication ? No reason why not. My point is that many of these protocols are more complex than I would certain want open to handle. Leave the complex stuuf to those modules and use the API they provide. The suggested syntax does not necessarily conflict with the above - the core might spot the xxx: scheme and try and load an xxx.pm from some well known path and hand off the open to that module. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ...Let He who taketh the Plunge Remember to return it by Tuesday.
Re: RFC 14 (v2) Modify open() to support FileObjects and
In message [EMAIL PROTECTED] Tom Hughes [EMAIL PROTECTED] wrote: The suggested syntax does not necessarily conflict with the above - the core might spot the xxx: scheme and try and load an xxx.pm from some well known path and hand off the open to that module. To follow up to myself I should add that there is also a second technique that achieves the same result. That is if the core provides a way for modules to register as handlers for certain types of filename - the when you load a module like LWP it would register things like http and ftp that it knows how to handle and open's for those types would be handed off to the registered handler. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ...Don't speak about Time, until you have spoken to him.
Re: RFC 51 (v2) Angle brackets should accept filenames a
"JE" == Jon Ericson [EMAIL PROTECTED] writes:
@foo = lazy grep
while( @foo ) { ... }
JE What does lazy grep do? How does this apply?
lazy would set the rest of arguments to be lazily evaluated. An iterator
that would call the function until the results are exhusted.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 69 (v1) Standardize input record separator (for
On Wed, 09 Aug 2000, Chaim Frenkel wrote: BCW Isn't that what the nebulous line disciplines are supposed to handle? Has anyone taken on RFCing line disciplines? I haven't seen anything on them, but everyone seems to be in agreement that we're going to have them. If no one else wants to bite the bullet, I'll at least throw something out that people can object to. (It seems to me that line disciplines, or at least the idea of Perl's implementation of line disciplines, precedes Perl 6. Is this my imagination, or can someone point me to an existing ref?) -- Bryan C. Warnock ([EMAIL PROTECTED])
Re: Summary of I/O related RFCs
"JE" == Jon Ericson [EMAIL PROTECTED] writes:
JE =item 33 (v1): Eliminate bareword filehandles. (language)
JE No discussion.
I think it carried unanimously.
JE =item 36 (v1): Structured Internal Representation of Filenames
JE (internal)
JE No discussion of the proposal that "Wherever Perl internally uses
JE filenames (in a very inclusive sense: filenames, directory names,
JE whatever) the components of the file name should be stored in a
JE platform-neutral structured format." It also included: "A vague
JE possibility: the proposed internal format could be designed to be
JE flexible enough to present also URLs/URIs."
Are URIs sufficiently descriptive?
JE Chaim also expressed concern that overloading and would create
JE confusion for perl and programmers. I said that they would simply
JE replace the file-globbing mode found in perl 5.
Please adjust that. My concern was for the parsing of some arbitrary
complex expression.
Hmm, I'll offer this as an alternative { hairy expression }
Then the parser can switch to block, and then discover it has to switch
the previously assumed less than into a operator.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 14 (v2) Modify open() to support FileObjects and
On Wed, Aug 09, 2000 at 07:26:29PM +, Nick Ing-Simmons wrote: Graham Barr [EMAIL PROTECTED] writes: On Wed, Aug 09, 2000 at 11:41:42AM -0500, Jonathan Scott Duff wrote: How about this? open '/etc/passwd'; # file OK open '/usr/local/bin/'; # directory (note the trailing '/') Portability, not all platforms use / Hmm. So that would be open 'file://etc/passwd'; open 'dir://usr/local/bin'; with the default open method being "file"? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
