himazu@isl.mei.co.jp (IMAZU Hideyo) (01/12/91)
"open" take an expression as FILEHANDLE argument. But "dbmopen" doesn't take an expression as ASSOC argument. In some situations, it is useful that "dbmopen" take an expression as ASSOC. For example, in a code as follows. @dbspec = ('data_a', 'a_file', 'data_b', 'b_file'); &dbopen(@dbspec); $data_a{...} = .... ....$data_b{...} ... .. &dbclose(@dbspec); .. .. sub dbopen { while ( @_ > 1 ) { dbmopen($_[0], $_[1], 0600) || die "cannot open $_[1]"; shift @_; shift @_; } } sub dbclose { while ( @_ > 1 ) { dbmclose($_[0]); shift @_; shift @_; } } -- IMAZU Hideyo(Imazu is my family name) himazu@isl.mei.co.jp Matsushita Electric/Panasonic, Osaka, Japan
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (01/29/91)
In article <HIMAZU.91Jan12114429@isl.mei.co.jp> himazu@isl.mei.co.jp (IMAZU Hideyo) writes:
: "open" take an expression as FILEHANDLE argument.
: But "dbmopen" doesn't take an expression as ASSOC argument.
: In some situations, it is useful that "dbmopen" take an expression
: as ASSOC.
Okay, I'll try to make that legal in 4.0.
Larry
utashiro@sran84.sra.co.jp (Kazumasa Utashiro) (01/29/91)
In article <11205@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: >> : "open" take an expression as FILEHANDLE argument. >> : But "dbmopen" doesn't take an expression as ASSOC argument. >> : In some situations, it is useful that "dbmopen" take an expression >> : as ASSOC. >> >> Okay, I'll try to make that legal in 4.0. Is it too much to want to use an expression for do's SOUBROUTINE argument? For example, I want to write like this: do $foo[$num](); do $foo{'bar'}(); I often fall in this trap when making something like a protocol switch. --- K. Utashiro utashiro@sra.co.jp
tchrist@convex.COM (Tom Christiansen) (01/30/91)
From the keyboard of composer@chem.bu.edu: :or : $prog = "do $foo[$num]();"; : eval $prog; : That could actually be $prog = $foo[$num]; do $prog(); and skip the costly eval entirely. But don't try to cheat and do this: do ($prog = $foo[$num])(); Now, I admit that I've sometimes wanted do $jump_table{$command}($arguments); There are other things that want simple scalar variables instead of expressions, too, like sort. I once wanted this: sort &foo @bar well actually this: sort &foo('$x{$a} <=> $x{$b}' @bar; as a work-around to the illegal sort { $x{$a} <=> $x{$b}; } @bar; but Perl was unamused -- it'll take sort $foo @bar; and that's it. Eventually, you know, one of these things is going to be the proverbial straw that sends the beast off to a dromedarian chiropractor. :-) --tom -- "Hey, did you hear Stallman has replaced /vmunix with /vmunix.el? Now he can finally have the whole O/S built-in to his editor like he always wanted!" --me (Tom Christiansen <tchrist@convex.com>)
utashiro@sran84.sra.co.jp (Kazumasa Utashiro) (01/30/91)
In article <1991Jan29.163953.15953@convex.com> tchrist@convex.COM (Tom Christiansen) writes: >> That could actually be >> >> $prog = $foo[$num]; >> do $prog(); Yes. That is the way I'm doing now. I think eval is the last way to do something in most cases. >> and skip the costly eval entirely. But don't try to >> cheat and do this: >> >> do ($prog = $foo[$num])(); That was the intermediate stage before I reached to the above result. Why you know? :-) >> Now, I admit that I've sometimes wanted >> >> do $jump_table{$command}($arguments); I don't want to complain about this at all. It isn't too bad and documented well. Just an idea. --- utashiro@sra.co.jp
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (01/31/91)
In article <283@sran84.sra.co.jp> utashiro@sran84.sra.co.jp (Kazumasa Utashiro) writes:
: I don't want to complain about this at all. It isn't too
: bad and documented well. Just an idea.
It's not a bad idea. I just don't think it happens often enough to be
worth the effort of dealing with all the shift-reduce ambiguities it
would introduce. The "do" operator is already too heavily overloaded,
and it would be easy to lose the trailing parens. (This is a problem
in C and all C-derived languages--in fact, in any language with a mixture
of prefix and postfix operators.) Even if the compiler can keep track
of the trailing parens, the poor slob trying to read the code may easily
overlook them. I think that forcing the programmer to name temporaries is
not always an evil.
This brings up the whole issue of pipelines vs. temp files, but you'll note
that a pipeline can be read left to right, while a typical C expression
has to be read from both ends at once, or perhaps from the inside out.
To a smart compiler, of course, it makes no difference which way you write
it, since the temporary can be looked at as a definition rather than
an actual storage location. I'm not claiming Perl is that smart yet.
Perl doesn't allow nested quote interpretation either, which also forces
you to make temporaries at times. I consider this to be an anti-obfuscatory
feature.
Larry