----- Original Message ----- From: "brian ray" <[EMAIL PROTECTED]> To: "Simon Cozens" <[EMAIL PROTECTED]> Sent: Monday, February 18, 2002 1:06 PM Subject: Re: Keys and Indices PDD
> Hello all. As the new guy here, I suppose I should say a few words > by way of introduction. My name is Brian Ray, and I'm a CPSC student > at U of Arkansas, Little Rock. I'm not a perl programmer <dons > fireproof cloak>, I'm a C programmer, but I don't think that's a > terrible hinderance. Anyway, I'll just jump right in and make an > ass of mysel... er, make some suggestions. > > > >Need discussion on whether C<OUT_OF_BOUNDS> is a good exception for > >this, or whether something else should be used. It's really a compiler > >screw-up, since code which indexes a non-aggregate shouldn't be > >generated. > How about INVALID_KEY? > > Next it selects the appropriate op. Register keys have the signature > > C<r> and constant keys have the signature C<kc>. For example: > > > > set P1["hi"], 1234 > > > > finds an op named C<set_p_kc_i>. On the other hand, > > > > set P1[S1], 1234 > > > > produces an op named C<set_p_r_i>. > > > > =over 3 > > > > =item C<Todo> > > > > This is only half implemented. The C<r> business may need to be > > documented in another PDD somewhere. This is also not going to scale > > to keys like C<P1;S1;123>, and I don't know how to do that. > > > > =back > > > > Keys with multiple key-pairs may need to be classed as constant keys. > I understand the desire to have a 1:1 mapping between opcode argument > types and the C functions which implement them, but that just isn't > practical in this case. I think > set P1["Hi"], 1234 > set P1[3], 1234 > set P1[1.5], 1234 > set P1["Hi";S1;3;2.5], 1234 > > should all invoke an op named set_p_k_i. The KEY_PAIR structure already > encodes the number of the arguments, and, while this does mean that all > of the arguments have to be passed as constants, I can't think of a good > reason for an agregate to have write access to it's keys. > > brian. >
