[comp.lang.perl] suggestion for dbmopen

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