Re: RFC 100 (v2) Embed full URI support into Perl
>>>>> "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes: NC> $htdoc = open uri "http://www.yahoo.com" or die; NC> with uri in the standard library NC> and also make it easy to stack the module that does uri at the top of 'file' NC> so that the default is to call the uri stuff. Is it just me, but I keep wondering how Uri Guttman gets into this. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 39 (v3) Perl should have a print operator
>>>>> "ABH" == Ask Bjoern Hansen <[EMAIL PROTECTED]> writes: >> Oh, why not? Does anybody actually *ever* check the return value of >> print? I think it's not as if we'd break a lot of code. ABH> uh, what? you don't do much socket programming now, do you? sockets ABH> breaks all the time. Disks runs out of space while you write to ABH> files. and so on and so on. Could someone enlighten this poor soul and tell me what I _can_ do with an error return from a print or close? Reporting it may be useless (disk full). While I'm asking, what does one do while switching around file descriptors and an error is returned. Is there anywhere to report it? -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 100 (v1) Embed full URI support into Perl
You're still showing non-portable examples. What is the win? And what does "file://z/docs/personal" become? Or for that matter "file://u/frankeh/Projects" become? (I happen to live at a mount point /u. You are squeezing a little too hard here. There are seperate problems to be solved, whether a single interface can do it all is still to be determined. Even if you are able to squeeze some of the protocols into open. It still requires that the lower level implmentation be visible to the user. Get is not sufficient. The http protocol has quite a bit of interaction that one may want to access. Similar the ftp protocol. All that this might do is be a shorthand. So I'm not sure that expending effort in this direction is that much of a win. Basically presenting all of these high level protocols with such a limited repetoire of operations is crippling. >>>>> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes: NW> Sam Tregar wrote: >> >> How is this better than File::Spec's approach? NW> File::Spec has the idea and representation dead on. However, the NW> interface is a pain; to write portable scripts you have to go through NW> some contortions. NW> With URI support, you still have to contort a little, but not as much. NW> Here's some better examples from an email I sent earlier: NW>$fo = open "file://c/docs/personal"; NW># Unix = /docs/personal# here, 'c' becomes '/' NW># Mac = :docs:personal# here, 'c' becomes ':' NW># Win = c:\docs\personal NW> Something like File::Spec can be used to perform the magic internally, NW> but you get the benefit of not having to call catfile explicitly. Perl NW> sees a URI and does its thing. Plus, URIs are familiar - most everyone NW> (even those unfamiliar with Perl) understands what the URI in the open NW> statement does. NW> Although the examples are terrible at showing it (sorry), full URI NW> support means more that just writing portable filenames. It means having NW> Perl understand http://, ftp://, etc, etc, so that it can do something NW> "really cool" with it. The upcoming v4 of RFC 14 will show how this is NW> an advantage. NW> -Nate -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 100 (v1) Embed full URI support into Perl
>>>>> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL>$fo = open "C:\Windows\System";# non-portable PRL>$fo = open "file://C|/Windows/System"; # portable In what way is the second example portable? I don't think it will do anything useful on any of my *nix boxes. PRL>unlink "/local/etc/script.conf"; # non-portable PRL>unlink "file:///local/etc/script.conf";# portable Nor this on a dos box. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 14 (v3) Modify open() to support FileObjects and
You forget that open() handles all the magic. "| ...", " ...|", and the rest of the family. Sysopen specifically doesn't. So one could easily (and does) use open to do the magic, and then uses sysread/syswrite to handle the dirty details of playing with a pipe. Oh, before I forget, one also needs to use sysread/syswrite if one is doing 4 arg select. Now, sysread/syswrite might possibly be eliminated if perl6 has its own stdio replacement and direct access or at a minimum coordination between 4 arg select and buffering were properly handled. (Calling Mr. Dan, Calling Mr. Dan...) >>>>> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes: NW> Chaim Frenkel wrote: >> >> >>>>> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes: >> NW> # Replaced by 'open sys' NW> sysopen NW> sysread # sys->read instead NW> syswrite# sys->write instead >> >> sysread and syswrite also work on files that were opened via standard >> open. It bypasses the stdio library. NW> Yeah, I know. The question is how frequently this is used. NW> Since you can't mix read/print with sysread/syswrite, my suspicion is NW> that most people use sysopen and then sysread/syswrite, or open then NW> read/print. This is what I've always done, personally (but then again NW> I'm not everyone either). :-) NW> Since sysopen only takes a few extra args, I don't think it's too much NW> of a hassle to require sysopen for sysread/syswrite access. It also NW> makes it clear this is a special type of file access that doesn't (and NW> shouldn't!) obey formats, regular reads/prints, etc. NW> That's my input. If lots of people are against me we can change this. NW> -Nate -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 14 (v3) Modify open() to support FileObjects and
>>>>> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes: NW># Replaced by 'open sys' NW>sysopen NW>sysread # sys->read instead NW>syswrite# sys->write instead sysread and syswrite also work on files that were opened via standard open. It bypasses the stdio library. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)
>>>>> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes: DLN> Chaim Frenkel wrote: >> >> Sitting on a unix box, and getting to C: on a windows box? DLN> That implies a whole pile of implementation details. Are you DLN> suggesting a Perl Orifice to run on all participating windows DLN> boxes? No. But the underlying protocol/transport layer may want the file name in the remote format. DLN> I'd DLN> like to call "open" with the arguments I can currently pass DLN> to "hose" from the netpipes package, that would simplify writing DLN> TCP clients. Sorry, I couldn't parse this. What did you mean by this. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)
>>>>> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes: NW> Many others have begged :-) for URI support in open(), so it'll be in NW> there. This seems like the easiest thing todo. No reason to reinvent the NW> wheel, URIs are a well-established platform-independent naming scheme. I'm not sure that it covers all the bases. It covers the universe that web servers are designed to handle. But what about the universe of devices. Or remote access to mounted volumes? Sitting on a unix box, and getting to C: on a windows box? I'll wait and see how the proposals shape up. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)
>>>>> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: >> Please explain why internally it needs to be represented as anything >> other than what the user passed in. JH> A flat string is a pain to handle because then you have to know JH> in which platform it was originally created: what semantics does JH> it obey, how to parse it. I don't see how your proposal solves the problem. It still has to know what the source/intended/target platform is. Why do all those acts have to be performed to do an open? Hmm, unless you are planning to have a direct perl <-> os layer. (A rewrite/stealing^wborrowing from sfio?) -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)
>>>>> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: JH> On Sun, Aug 13, 2000 at 09:40:07AM -0400, Bryan C. Warnock wrote: >> This all seems like a lot of work for (what I would consider to be) the JH> Read carefully the subject: *internal* representation. If you are JH> opening a file with open() or sysopen(), you supply a string with your JH> native FS semantics and think no more of it. What RFC? I couldn't find it on http://dev.perl.org/rfc/ Please explain why internally it needs to be represented as anything other than what the user passed in. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)
>>>>> "JV" == Johan Vromans <[EMAIL PROTECTED]> writes: JV> @parts = qw(sy $ foo bar 262); JV> Now, create a file in the same directory with the same type, and name JV> blech. Any idea? I don't like this but how about $resource = File::Generic "." $resource->name = "new name with all other parts left alone"; $fh = open $resource->asNativeFormat() Blech, but possible. (Stolen parphrased but liberally from the Symbolics manual) -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)
>>>>> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> I agree with Dan: people do seem to get into "have to" mode awfully
JH> soon and easily. The proposed framework is supposed to make it easy
JH> to handle file names and make Perl internals (well, not internal-
JH> internals, but the IO layer) better support multiplatform situations,
JH> both when scripts have to run on multiple platforms, and when
JH> an application is running on multiple platforms _simultaneously_,
JH> servers-clients, peers-peers, etc.
Fine. Then all the 'parts' of a generic filename (or should that be
a resource name) are pure strings?
Who supplies the logic to scrunch them together into an understandable
(to the os) form?
And how do we make it easy to pass in a name to open?
$fh = open Perl::Canonical(Host=>"remote"
,OS=>"VMS"
,Device=> "DAO"
,Path=>("path", "to", "resource")
,Name=> "filename"
,Type=>"txt"
,Version=> ":oldest"
);
Seems messy.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)
>>>>> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes: NW> Chaim Frenkel wrote: >> >> The VMS (and TOPS20) advocates will scream here. Versions are part of >> the file name. The default is the latest version. But the filesystem >> automatically versions files. >> >> Hmm, if we support versioning files, will perl have to support emacs >> versioned files? /foo/bar/bash.c.~356~ NW> I would argue they should write File::Versioning or File::VMS or NW> File::Emacs to deal with type of thing. Than so should the DOS and Windows camps. Either we go out of our way to make as many people happy as possible or we should stick to our roots on unix. BUt clearly Larry isn't going that route. We should think about the problem and see how we can accommodate them. NW> Is there really that much VMS Perl out there? :-) Yes. Check the p5p archives. And I believe that our esteemed internals head honcho is (or was) one of them. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 14 (v3) Modify open() to support FileObjects and
>>>>> "JSD" == Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
JSD> I originally didn't like this but the more I think about it, the more
JSD> I like it ... as long as the default handler knows about URIs :-)
JSD> I'd like
JSD>open "http://www.perl.com";
JSD> do DWIM.
(Some random thoughts.)
What hasn't been discussed, is
Are files (or perhaps resources) named natively or in a portable fashion?
If portable, then
for (@ARGV) { open $_; ... }
has to DWIM both portable and native formats.
If native, then the URI has problems.
There also comes the overhead (programming effort) of converting
_some_ resource names to native format for output to the user.
And deciding which of those resource names should be transformed
will be tough.
And how does one open sockets or connections to custom servers?
Will open take over the work of socket() and family? What is the
resource supposed to look like?
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)
>>>>> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes: NW> just deal with filenames universally this would be a big win (leave NW> acls, permissions, versions, etc to something else). The VMS (and TOPS20) advocates will scream here. Versions are part of the file name. The default is the latest version. But the filesystem automatically versions files. Hmm, if we support versioning files, will perl have to support emacs versioned files? /foo/bar/bash.c.~356~ -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)
Here's a list of attributes that I found in my old Symbolics Reference Guide to Streams, FIles, and I/O. (March 1985) Host Device Directory Name Type Version Plus it needs to handle cross-system support. How to specify the name of a unix file when running on a VMS system. A few of the features, I found while skimming through the document. Wildcard conventions, relative directories, os dependent naming conventions. >>>>> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes: NW> Here's an idea. Our new nifty fileobjects ($fo) could have some "jars" NW> where path info is stuck internally automatically. We could have methods NW> for: NW>$fo->pathdrive # Windows drive NW>$fo->patharray # array of split-up filename NW>$fo->pathdelim # / or \ or :: or ? NW> So trace this call: NW>$fo = open "C:\Windows\System\IOSUBSYS\RMM.PDR"; NW>$fo->pathdrive = "C:" ; NW>$fo->patharray = [ Windows, System, IOSUBSYS, RMM.PDR ]; NW>$fo->pathdelim = "\"; NW> So, this would be the internal representation of the filename. A UNIX NW> one would be similar, it's just that the drive jar would be empty: -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Line disciplines (was Re: RFC 69 (v3) Standardize input record separator)
I think a more generic approach would be thinking of it as a series of
filters. With the :attributes being hints to the open of what to push
on the filehandle.
This would allow dynamic additino and removal of the filters while the
filehandler were still active. The purely open approach would be
somewhat more static.
The issue would be speed. Adding lots of little pieces of code each of
which has bookkeeping overhead (its own plus the perl invocation
of the filter) would slow down perl's io famed text processing speed.
>>>>> "BCW" == Bryan C Warnock <[EMAIL PROTECTED]> writes:
BCW> standard line discipline syntax of :foo, or use something as simple as
BCW> a Perl hash, and would not necessarily be limited to the open call.
BCW> (This is all a wag, don't take it as gospel.)
BCW> So you'd potentially have hints like so:
BCW> :bin
BCW> :text
BCW> :text=ascii
BCW> :text=utf8
BCW> :text=utf32
BCW> :text=ebcdic
BCW> :text=some_weird_proprietary_format
BCW> :block=
BCW> :line=
BCW> :line=dos
BCW> :line=mac
BCW> :line=unix
BCW> :line=/like, you know?/
BCW> :mod=chomp
BCW> :mod=split
BCW> :mod=\&do_some_funky_pre_processing
BCW> That would allow you to do stuff like the following.
BCW> open FOO, "foo_file", :text=ascii, :line=unix, :mod=chomp;
BCW> while ()
BCW> {
BCW># $_ = an ascii line, delimited to \n, but without the \n;
BCW> }
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 69 (v3) Standardize input record separator (for
>>>>> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL> =head1 ABSTRACT PRL> The default input record separator is not safe for all input files PRL> on all platforms. There should also be support for Unicode line PRL> separator (U+2028) and paragraph separator (U+2029). You want to add, "non-native text files" somewhere in there. PRL> =head1 DESCRIPTION PRL> The input record separator should match the platform's C compiler PRL> mappings of "\r\n" (CRLF), "\n" (LF) and "\r" (CR), which are often PRL> (but not always, e.g., EBCDIC-based platforms [Peter Prymmer]): What does this mean? I can't make out what you are trying to say. PRL> 000D 000A PRL> 000A PRL> 000D This are not the line seperators on my platform. If this were in a file, I would not consider it a text file. You have embeded nuls in there. PRL> For Unicode-capable platforms, the input record separator should PRL> also match: PRL> 2028 PRL> 2029 What does unicode-capable platform mean? It should depend upon the file I'm reading not on the capablities of the os. PRL> Given this input file: PRL> D O S CR LF0044 004F 0053 000D 000A PRL> U n i x LF0055 006E 0069 0078 000A PRL> M a c CR 004D 0061 0063 000D PRL> l i n e LS006C 0069 006E 0065 2028 PRL> p a r a PS 0070 0061 0072 0061 2029 PRL> l i n e006C 0069 006E 0065 Same problem. I don't have embedded nuls in any of my text files. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 69 (v2) Standardize input record separator (for
I also think you are missing a point. The stdio library (or it's returns "\n" for the native line endings. The un-RFCed stdio replacement (sfio or a perl home grown one) might do the same. So... The correct line ending is "\n", you are adding an other line ending for the non-native version. I'd claim that this is closer to the IO layer rather than another pragma. >>>>> "SH" == Simply Hao <[EMAIL PROTECTED]> writes: >> But there is no way that I want under, any circumstance, _all_ >> line endings active at the same time. SH> Why not? SH> Well, how about this proposal then? SH> DOS, Mac, Unix: SH> use newlines "\015\012", "\012", "\015"; SH> OS/390: SH> use newlines "\r", "\025"; SH> Weird OS: SH> use newlines "\t"; SH> Something like that? SH> Okay, maybe what I really want is $/ to be a regex. SH> -Hao -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 69 (v2) Standardize input record separator (for
I completely disagree. How do you know that I want 5 lines. Perhaps I want only 3? You are assuming that within my file I will want all possible line endings to be line endings. That is simply not true. You might want to argue for the perl IO subsystem to intuit the line ending (note the singular) in use and then handle it correctly. But there is no way that I want under, any circumstance, _all_ line endings active at the same time. >>>>> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL> Given this input file (in UTF-8): PRL> D O S CR LF0044 004F 0053 000D 000A PRL> U n i x LF0055 006E 0069 0078 000A PRL> M a c CR 004D 0061 0063 000D PRL> l i n e LS006C 0069 006E 0065 2028 PRL> p a r a PS0070 0061 0072 0061 2029 PRL> This should work as expected on as many platforms as possible: PRL> my @lines = ; PRL> The @lines array should contain five elements. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 14 (v2) Modify open() to support FileObjects and
What about native extensions? I think VMS (and the old TOPS10) had versions as part of the file name. Do URIs have this capablity? And what does a read of a directory return? URIs or Native? A job for binmode, err, readmode, or a line discipline? >>>>> "JSD" == Jonathan Scott Duff <[EMAIL PROTECTED]> writes: JSD> 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 / JSD> Hmm. So that would be JSD>open 'file://etc/passwd'; JSD>open 'dir://usr/local/bin'; JSD> with the default open method being "file"? -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
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 FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 69 (v1) Standardize input record separator (for
>>>>> "BCW" == Bryan C Warnock <[EMAIL PROTECTED]> writes: BCW> 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? BCW> I haven't seen anything on them, but everyone seems to be in agreement BCW> that we're going to have them. If no one else wants to bite the BCW> bullet, I'll at least throw something out that people can object to. BCW> (It seems to me that line disciplines, or at least the idea of Perl's BCW> implementation of line disciplines, precedes Perl 6. Is this my BCW> imagination, or can someone point me to an existing ref?) Sure did. Go do some searches on p5p. Many of the comments referenced sfio disciplines and/or TCL channels. Go forth and steal^w borrow^w learn. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
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 FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 14 (v2) Modify open() to support FileObjects and
Fits right in with my (yech) suggestion of haveing a registry of all installed modules. This could handle the locating of the correct versioned module, we could add the open handlers. Though is there a way of making it versioned? (Do we need to?) open "ftp(version=1,author=NIS)://" (Ugly.) >>>>> "TH" == Tom Hughes <[EMAIL PROTECTED]> writes: TH> That is if the core provides a way for modules to register as TH> handlers for certain types of filename - the when you load a TH> module like LWP it would register things like http and ftp that TH> it knows how to handle and open's for those types would be handed TH> off to the registered handler. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 69 (v1) Standardize input record separator (for
>>>>> "BCW" == Bryan C Warnock <[EMAIL PROTECTED]> writes: BCW> Isn't that what the nebulous line disciplines are supposed to handle? Has anyone taken on RFCing line disciplines? -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 51 (v2) Angle brackets should accept filenames a
>>>>> "JE" == Jon Ericson <[EMAIL PROTECTED]> writes:
JE> Chaim Frenkel wrote:
>> What does
>>
>> $foo = <"filename">;# 1
>> $bar = <"another">;
>> $gaz = <"filename>; # 2
JE>^ add " here
>> Does #2 get the second line or the first?
JE> $gaz contains the second line. Otherwise this:
JE> while (<'filename'>){print;};
JE> won't work. This gets a little hairy, I admit.
Actually they are two different problems. The while loop can be
internally replaced with an open, while, close. Or with a local
version of a filehandle that _only_ is valid at that line or
block.
The same string being the same file is more of an issue. Just
consider having two different modules/packages, opening the same
file. You _might_ want them to have different meanings.
>> Can the <> contain a function?
JE> 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.
JE> To my eye angle brackets signify input.
Perhaps but what about Damien's proposal
if ($x < foo() > $y) { ... }
Remember perl has to intuit among, < file >, <, <= , !<, etc.
I'd rather not add to the load.
However, there is the concept of lazy evaluation that has been
proposed so you might be able to get your way.
@foo = lazy grep
while( <@foo> ) { ... }
However, I'd rather you limit your proposal to being valid only at a
single spot in the code. Similar to the .., and ... toggle
operators. So that different usages of the same string mean different
filehandles.
I'm not quite in favor of the proposal, since DWIMing the meaning of
a string doesn't seem to be clear. Perhaps you should go through all
of the possiblities.
You will also have to consider, if the string is to be put through
magic open? or strictly valid file and directory names. What about
the proposed URL intuiting? Should that be accepted?
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 69 (v1) Standardize input record separator (for
>>>>> "BL" == Bart Lateur <[EMAIL PROTECTED]> writes: BL> On 09 Aug 2000 12:00:55 -0400, Chaim Frenkel wrote: >> There was no mention of cross-platform line-ending support. >> I suggested a while ago on p5p an improved binmode(), that might do >> such magic among other things. BL> Then it should do the *inverse* thing that binmode() does. This magic BL> should only apply to text files, for whatever platform they originate BL> from. If a file is binmode'd, Perl should keep the data as is, no BL> conversion (or even interpretation) of the input, whatsoever. It doesn't have to be called binmode(). Let's call it readmode(). readmode(FOO, "CRLF"); readmode(FOO, "os:macintosh"); readmode(FOO, "os:MVS encoding:ebcdiic"); Wait, this sounds like a job for input/output filters. Forget I said anything. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 69 (v1) Standardize input record separator (for
That wasn't what the original RFC was discussing. There was no mention of cross-platform line-ending support. Because I can validly embed a "^M" into my unix text file and it will be quite valid. Under the RFC proposal I will suddenly get an unexpected line ending. The problems of intuiting line-endings is an open issue. I don't want perl getting in my way without being asked. I suggested a while ago on p5p an improved binmode(), that might do such magic among other things. >>>>> "BL" == Bart Lateur <[EMAIL PROTECTED]> writes: BL> On 09 Aug 2000 10:34:27 -0400, Chaim Frenkel wrote: >> Please explain in what way "\n" is not safe on all platforms? >> >> On all platforms, the actual line seperators are translated (except >> under binmode()) to "\n". BL> Try processing a Mac file on Unix, or vice versa. You'll soon see why. BL> Your scheme only works with platform native files. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 51 (v2) Angle brackets should accept filenames a
What does $foo = <"filename">;# 1 $bar = <"another">; $gaz = <"filename>; # 2 Does #2 get the second line or the first? Can the <> contain a function? 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. >>>>> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL> =head1 ABSTRACT PRL> In scalar context, the next line (or file) is read from the first item PRL> in LIST. When the first item returns undef, the next item is read. PRL> When there are no more items left, undef is returned. PRL> Inside a while loop (or the conditional section of a for(;;) loop), $_ PRL> is assigned to the next line (or file) and tested for defined-ness. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 69 (v1) Standardize input record separator (for
Please explain in what way "\n" is not safe on all platforms? On all platforms, the actual line seperators are translated (except under binmode()) to "\n". If you do decide to switch to binmode() you are in non-portable territory. >>>>> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL> =head1 ABSTRACT PRL> The default input record separator is not safe for all input files PRL> on all platforms. PRL> =head1 DESCRIPTION PRL> For easier portability, the default input record separator should PRL> at least match /\015?\012/, so that the following works on as many PRL> platforms as possible: -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 14 (v2) Modify open() to support FileObjects and
I can see a need to keep the sys* functions (and perhaps add more.) When the coding is at a high level, some simple things become impossible. Many years ago, I read through the volumes on the Apple Toolbox. I don't recall much, but I do recall what seemed to be an effort on the designers part to supply both low level and higher level capablities. If it is possible to get both the higher level and the lower level implementation layers to be active at the same time would be great. But don't lose the access to the bare metal. >>>>> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL> The open() functions would have to be altered to accept this new syntax PRL> and return full-fledged B. The functions C, PRL> C, C, and possibly many others must be rewritten PRL> to serve as "shortcuts" to the new extensible C. PRL> With regards to now-obsolete functions (such as C, C, PRL> C, and many more), we should make one of two choices: PRL>1. Make them shortcuts to the long form PRL>2. Remove them outright PRL> If we choose #2 (I think #1 might actually be the right answer), we PRL> should probably make nicknames for these modules, such as "dir" for PRL> IO:Dir, "socket" for IO::Socket, and so forth, so a person can type: PRL>$dir = open "/usr/bin", dir; # instead of IO::Dir PRL> Finally, to make the full, extensible class form useful, we will have to PRL> figure out what type of modular hooks it will have. They may look like PRL> C, with hooks for every operation, or they may be completely PRL> different, just requiring an C function in the module. If all PRL> modules agreed to return a consistent object from this C call, PRL> then the file routines could potentially be highly-optimized, since PRL> there would only have to be one core set. If possible, this is what I'd PRL> like to see. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
