Re: RFC 181 (v1) Formats out of core / New format syntax
On Mon, 18 Sep 2000 10:57:49 +0200, H.Merijn Brand wrote: >perl5 formats do NOT support lexicals Eh? It looks like it, though. my $foo; format STDOUT = @>>> $foo . $foo = 123; write; $foo = 45; write; It looks *so much* that way, that I think you must be wrong. -- Bart.
Re: RFC 181 (v1) Formats out of core / New format syntax
On Thu, 14 Sep 2000 12:41:04 -0700, Glenn Linderman wrote: >> 1) With a string, there can be no compile-time check on the variables. >> If one isn't found, you can, at best, get a runtime error. > >What compile time checks are you expecting on the variables? For example: Well, for one: "use strict" should be able to do its job on these format variables. But I'm not talking about just the variables. I would expect a compile time check on the format string. Oh well, maybe I'm expecting too much. There isn't a compile time check on (s)printf format strings, either. -- Bart.
Re: RFC 181 (v1) Formats out of core / New format syntax
On Wed, 13 Sep 2000 22:49:14 -0700, Glenn Linderman wrote: >So who needs a special format type? Just need a string. It becomes a >format when you use it as such... So just > > my $frm = <<'.' >@<: @ >$name, $ssn >. I, for one, can see two problems with this. And I'm not an expert. Both are related to the variables. 1) With a string, there can be no compile-time check on the variables. If one isn't found, you can, at best, get a runtime error. 2) What about lexical variables? Suppose that $name is a lexcial variable. If this format string is interpreted in another module, there's no way that that module can get a grasp on the lexical $name. -- Bart.
Re: RFC 39 (v3) Perl should have a print operator
On Fri, 8 Sep 2000 01:18:19 -0700 (PDT), Ask Bjoern Hansen wrote: >I really don't understand why you want to have what's printed. It is handy, sometimes. But I do think that the overhead of creating a longish string every time you print something, which is then simply discarded, is not really acceptable. I expect a rather significant slowdown. A rough guess: 20%, which that is the slowdown I onotice if you print with $\ set to "\n" instead of to nothing. It's just not worth it. -- Bart.
Re: RFC 39 (v3) Perl should have a print operator
On Tue, 05 Sep 2000 18:37:11 -0600, Tom Christiansen wrote: >Those are not the semantics of print. It returns true (1) if successful, and >false (undef) otherwise. You cannot change that. If I write print "0", it >bloody well shan't be returning false. 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. Problem is: if you need defined() to see if the print was succesful, you cannot return what was printed as well. It's one thing or the other. So you cannot have it both ways. -- Bart.
Re: RFC 39 (v3) Perl should have a print operator
On Tue, 05 Sep 2000 16:46:03 -0700, Nathan Wiger wrote: >Would this be solved if print returned the string it printed? This seems >to be what everyone's getting at: > > my $output = print $r->name . " is $age years old\n"; I think that's the idea... and print may return undef if it fails to print, and the printed string otherwise (always defined, even if it's an emtpy string). Also, print @items; should then return join($,, @items).$\ -- Bart.
Re: RFC 39 (v3) Perl should have a print operator
On 31 Aug 2000 06:22:10 -, Perl6 RFC Librarian wrote: >Perl should have a print operator >Perl supplies an operator for line input - angle brackets. This is no >analogous operator for output. I propose "inverse angle brackets": > >>"Print this line.\n"<; This is not symmetrical. For input, the handle is marked as a source: $data = ; In order to be symmetrical, your ousput handle should look and act like a sink: >STDOUT< = $data; There. Now it's symmetrical. I doubt if it has any advantage over print. But then OTOH we could just replace with readline(HANDLE). Same thing. -- Bart.
Re: Line disciplines (was Re: RFC 69 (v3) Standardize input record separator)
On Wed, 16 Aug 2000 07:39:33 -0700 (PDT), Dave Storrs wrote: > The idea of having two different regex "languages" in Perl makes >me very, very nervous. Potential for confusion It should. However, I was talking about two different rgex implementations, not two different languages. I would make the notation the same for both. Except: there are things that you generally can't do with a DFA, such as capturing submatches, and repeated matches like /(['"]).*?\1/ (--> the "\1"). I think that's about it. And the DFA would only be used for input line terminator scans. No user choice. -- Bart.
Re: Line disciplines (was Re: RFC 69 (v3) Standardize input record separator)
On Fri, 11 Aug 2000 10:31:55 -0400 (EDT), [EMAIL PROTECTED] wrote: >Since what I proposed is obviously the wrong thing to do, I'm >wondering whether I should try redrafting RFC 69 or withdrawing it >completely, after which hopefully someone else will make a better >proposal. Please let me know. Thanks. I don't think it's completely wrong, but it shouldbe too radically different either. I too think that the input file separator should have regexish features, if the programmer wishes so. Now, one can only set $/ to a fixed string, which is inflexible if one doesn't know if one processes a Unix of a Mac file. My thoughts would be: a DFA regex engine, i.e. a state machine which is controlled by the next character in the input stream. No backtracking, very fast. But: no backreferences either, so the regex syntax will be more limited, than what the generic regex engine can process. I think that for this kind of application, we don't need it. -- Bart.
Re: RFC 69 (v2) Standardize input record separator (for
On 10 Aug 2000 17:02:01 -, Perl6 RFC Librarian wrote: >The input record separator should match one of these (in UTF-8): > >000D 000A >000A >000D >2028 >2029 Just a technical correction: that is not UTF-8. That is plain and simply the hex representation of the ord of the 16-bit Unicode character; UTF-16 if you insist. >=head1 IMPLEMENTATION > >? Something regexish, I would think. I wouldn't recommend doing this with Perl's normal regex engine. Instead, a dedicated, simpler, and hopefully much faster, DFA regex engine (virtually as fast as the current fixed string search, at least, that's my hope) ought to be employed. It looks to me like Perl should distinguish between 16-bit Unicode text files and plain old Ascii-compatible (incl. UTF-8 files) files. I wonder if the program shouldn't be notified that this is indeed a Unicode file. -- Bart.
Re: RFC 14 (v2) Modify open() to support FileObjects and
On 10 Aug 2000 08:35:18 +0100, Piers Cawley wrote: >> Allowing URI/URL syntax can perhaps dodge the "portability" issue >> URLs use / so if user thinks URL they think /. > >No! > >Yet more reasoned criticism from me eh? > >Seriously: Perl is not the web, the web is not perl And some more from me: conversion from plain directory path into an URI/URL is not always trival, if the path contains some unusual characters. -- Bart.
Re: RFC 69 (v1) Standardize input record separator (for
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. Then it should do the *inverse* thing that binmode() does. This magic should only apply to text files, for whatever platform they originate from. If a file is binmode'd, Perl should keep the data as is, no conversion (or even interpretation) of the input, whatsoever. -- Bart.
Re: RFC 69 (v1) Standardize input record separator (for
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". Try processing a Mac file on Unix, or vice versa. You'll soon see why. Your scheme only works with platform native files. -- Bart.
Re: Treating filehandles like strings
On 09 Aug 2000 09:40:29 +0100, Piers Cawley wrote: >> Now, what you can do, is stat() on the filehandle, and pick out the >> device ID and the inode number. That combination is unique for each >> file. > >And what happens when its a tied filehandle? Or are we going to >require that the tying class provides a STRINGIFY method as well? Required? No. The default for stringify is the familiar "Foo::Bar=HASH(0x8a6f088)" format. If you're too lazy to implement it, you get the same as you have now. It will be used mostly for debugging purposes, anyway. If in some way open() is used internally with a real file handle, the data coming from there could be incorporated in your "stringified" output. -- Bart.
Re: Treating filehandles like strings
On Tue, 8 Aug 2000 16:32:26 -0500, Jonathan Scott Duff wrote:
>I sincerely hope you really mean "Let's make ``open() or die''
>optional" Exceptions should be integrated into the language but Ye
>Olde "returns undef on error" should still be available as well.
>
>
> try { $fh = open("foo") } catch { die "Oops" } # pick your syntax
> $fh = open("foo") or die "Oops";
You may hope all you want. But what I gathered, and what I liked a lot,
was the idea that:
use Fatal;
$fh = open("foo.txt");
would act pretty much as if you had written:
$fh = open("foo.txt") or die "Can't open file \"foo.txt\": $!";
but for every file you open. Writing all those "do or die"'s get pretty
tiresome after a while.
If you don't want a failed open() to be fatal, you could do:
use Fatal; # maybe the default, in, say, perl7?
{
no Fatal;
$fh = open("foo.txt");
}
or in an eval BLOCK, for all I care.
--
Bart.
Re: Treating filehandles like strings
On Tue, 8 Aug 2000 15:12:27 -0400, Bennett Todd wrote: >One of the most valuable features was that the very large majority >of the helper routines I used, were simply wrappers around the >standard facilities, that didn't require any error checking: the >routine succeeded, or it printed a suitable error message and then >died. Yes. Very nice. >and I'll breathe a big sigh of relief when I >can just add "use Fatal qw(:all);" to the top of all my perl scripts >and forever more ditch all the " or die ..." clauses. Yes! Yes yes yes! Let's get rid of "open ... or die"! -- Bart.
Re: Treating filehandles like strings
On Mon, 07 Aug 2000 17:43:29 -0700, Nathan Wiger wrote: >> I'd rather have a filehandle stringify to >> the filename instead. > >Great minds think alike. :-) I was actually going to add this to the new >version of the open() RFC as a possible use of RFC 49's >soon-to-be-renamed STRING method. > >Now I know I have at least I have one supporter! ;-) This question has been asked a few times on comp.lang.perl.misc. It is in general not possible. On Unix, a file can have more than one name. The name can be changed while the file is open. Do you want the filehandle to track that? Another file could have taken the name, after the first file was opened. It's even possible that the name is deleted, so there IS no more name for it. Now, what you can do, is stat() on the filehandle, and pick out the device ID and the inode number. That combination is unique for each file. But, the whole world is not Unix. If you want something to be a part of Perl's core, it should be portable as well. -- Bart.
