Re: RFC 229 (v2) Variable interpolation on demand.
"John L. Allen" wrote:
Um, what would your proposal gain you over
$z = eval "qq{$y}";
other than conciseness, elegance and speed (which may be quite enough!) ?
$y = '};system "rm -rf *";qq{';
--
Robert Mathews
Software Engineer
Excite@Home
Re: RFC 288 (v2) First-Class CGI Support
Alan Gutierrez wrote: HTML::Embperl stuffs form input into a hash just as proposed here. For multiple values it creates a tab-delimited string. This will not present the above trouble with commas, since when the user, for some odd reason, enters "Ann Arbor\tMI", in most browsers the input focus will jump to the next input on tab, and the tab does not get entered into a field. Netscape on Solaris has this tabbing behavior for text fields, but allows you to enter tabs in text areas. I guess your solution would be workable, though. -- Robert Mathews Software Engineer Excite@Home
Re: RFC 229 (v2) Variable interpolation on demand.
"David L. Nicol" wrote: it's not a new feature. It's amazing the subtle control you can get with s/(\$...)/$1/ge depending on your You mean /gee, right? Hadn't thought of that. /ee makes my brain hurt. -- Robert Mathews Software Engineer Excite@Home
Re: RFC 288 (v2) First-Class CGI Support
Nathan Wiger wrote:
1. make a listref only for multiple values:
@name = @{$CGI{name}} if ( ref $CGI{name} eq 'ARRAY' );
Ick. That piece of code is small enough, but it's going to end up
replicating itself everywhere %CGI is accessed. This will be a fruitful
new source of bugs when people forget to check Cref $CGI{name}, and a
maintenance nightmare when someone makes a small like adding "multiple"
to a select tag.
But I don't think listrefs are needed in all contexts, since you should
know which elements will likely have multiple values (checkboxes, etc).
Maybe (and I stress maybe) the programmer knows, but the code that
parses into %CGI doesn't know whether a parameter is from a checkbox
group with only one value checked, or something else.
2. make it a comma-delimited string:
$name = $CGI{name};
@name = split ',', $name;
The problem arises if your data has commas in it.
Double ick.
Maybe %CGI is tied. Fast embedded tie, like in Perl 6. :-)
It looks to me like FETCH is always called in scalar context. Even
saying C@foo{...} results in multiple scalar fetches. That could be
changed, I suppose, but it makes me twitch. Maybe someone who knows
ties better could comment on this.
--
Robert Mathews
Software Engineer
Excite@Home
Re: RFC 288 (v2) First-Class CGI Support
Parse the CGI GET/POST request, returning CGI variables into %CGI
(regardless of the source) in an un-HTTP escaped fashion
How are you going to handle multiple values for the same parameter?
With CGI.pm, you can say
@values = $q-param("foo");
Are you going to make the values of %CGI listrefs? That should have
been spelled out before you froze the RFC. Also, it seems a bit
inconvenient if you always have to say C$CGI{bar}[0] when you just
want one value.
Or would you rather have %CGI magically notice what context it's in?
*Shudder*
--
Robert Mathews
Software Engineer
Excite@Home
Re: Perl6Storm: Intent to RFC #0101
Russ Allbery wrote: I have a very serious problem with use English, namely that it makes Perl code much more difficult to read and maintain for people who know Perl ... and don't know use English. Why can't they learn to use it? Are you saying that nothing is worth knowing unless the oldsters know it already? It's not that I want to jam English down everyone's throats. But Nate asked, "does anyone want this," and I said, "yes." Or at least, I would want it if it worked. I know what $/ does; I double-take at $INPUT_RECORD_SEPARATOR and am never sure whether it's a user's personal global variable or $/ or some other thing. And $ARG and $MATCH both really look like global variables to me and I'd hunt through the program trying to find where they're defined for a while before realizing they're weird use English things. You'd learn to recognize the long variable names if you used English regularly. It's a chicken-and-egg problem, but not a very difficult one. -- Robert Mathews Software Engineer Excite@Home
Re: Expunge use English from Perl? (was Re: Perl6Storm: Intent to RFC #0101)
Adam Turoff wrote: On Wed, Sep 27, 2000 at 04:39:32PM -0700, Nathan Wiger wrote: My personal feeling is that I'd love "use English" to be expunged from the language altogether - it's unnecessary bloat that only increases the number of mistakes that people can make. But I'm not sure if I have the guts to write that RFC just yet. ;-) Are you talking about the overlong variable names? Aliasing -X is being proposed through a 'use english;' mechanism. It's a good thing we've got Larry Wall to untie the Gordian knot of perl6. One rfc to add more english, one to take it away. -- Robert Mathews Software Engineer Excite@Home
Re: perl6storm #0050
Simon Cozens wrote: (defun Schwartzian (func list) (mapcar (lambda (x) (car x)) (sort (mapcar (lambda (x) (cons x (funcall func x))) list ) (lambda (x y) ( (cdr x) (cdr y))) ) ) ) Maybe you'd prefer this: defun Schwartzian func list mapcar lambda x car x sort mapcar lambda x cons x funcall func x list lambda x y cdr x cdr y I know which I'd rather read. Ok, you've proved that lisp doesn't make sense without all those annoying parentheses. Congratulations. Fortunately, perl isn't lisp. Why does removing the parens force you to jam everything together on two lines? The only reason I can think of is that you're using some fancy autoindenting lisp editor. Fortunately, perl doesn't force you to use a special editor just to tame the obvious shortcomings of the language syntax. Perl *lets* you include parentheses, or not, whichever makes the code easier to read. Yeah, you can write ugly or broken code by leaving too many out. So? -- Robert Mathews Software Engineer Excite@Home
Re: \z vs \Z vs $
Tom Christiansen wrote: Don't forget /s's other meaning. Do you enjoy making people ask what you're talking about? What other meaning did you have in mind, overriding $*? -- Robert Mathews Software Engineer Excite@Home
Re: RFC 72 (v3) Variable-length lookbehind: the regexp engine should also go backward.
Hugo wrote: The difficulty with variable-length lookbehind (let's call it VLLB) is this: suppose that we want to match "abcdef...xyz" =~ /(?=x+)y/. In theory, to check the possible /x+/ matches in the right order [0] we need to check whether there we can match 0 characters at offset 0 (no), then check whether we can match 1 character at offset 0 or 0 characters from offset 1 (no), then check whether we can match 2 characters from offset 0, or 1 from 1, or 0 from 2 ... and so it goes on. So we'd be trying a complete subpattern, of arbitrary complexity, against O(n^2) strings. You're assuming that the regex engine will always match things forward, but the subject of this thread says it should be able to go backward. You're interpreting (?=ab*) to mean "try to match /ab*$/ against what we've already scanned". But what if it meant "try to match /^b*a/ against reverse(what we've already scanned)"? Notice, the pattern is reversed too. There are probably some gotchas associated with reversing patterns. Such as $ matching \n at end-of-string, while ^ doesn't match \n at the beginning. I'll be optimistic and hope these are solvable. The implementation could do the reverse match by making the regex engine scan the string in reverse, as was suggested. That seems like a huge, and possibly quite inefficient, change to the code, as several people have pointed out. Alternatively, it might be possible to actually make a reversed copy of the string (once, before starting the match at all) and do the reverse match against that. This should have negligible impact on code that doesn't use variable length lookbehind. It probably wouldn't play too well with the "incremental pattern matching" proposals that are being tossed around, though. Ah, well. Doing the matching in reverse would have some subtle effects. For example, in (?=([ab]+)([bc]+)), the second greedy match would gobble up b's before the first one saw them. I don't see that this is a problem, as long as this behavior is documented. What about nesting lookbehinds inside of lookbehinds? Ouch... -- Robert Mathews Software Engineer Excite@Home
Re: Extended Regexs
James Mastros wrote: [/f for fast DFA regexen] Jeremy Howard wrote: The choice of algorithms is a great idea, but why do we need a modifier? Isn't it a pretty straightforward set of rules that allow us to decide if a DFA matcher will work? It would be a lot nicer if Perl could just notice that the regex could be handled by its DFA matcher, all by itself. That would be nice, too, but a modifier would let you ensure that the DFA matcher was being used. You wouldn't have to guess whether a particular construct was DFA-able or not. -- Robert Mathews Software Engineer Excite@Home
