Re: [bug-gawk] array initialization

[Andrew J. Schorr]

Hi,

On Sat, Jan 05, 2019 at 11:29:15AM -0700, address@hidden wrote:
> Coding while sick is probably not a good idea.  Get some rest.

Agreed. I'm feeling a bit better now.

> > It remains difficult to debug these types of issues because typeof doesn't 
> > shed
> > any light on the backend array type. One could imagine adding an optional
> > second argument to typeof that will contain an array returning various
> > attributes of the variable, with no guarantee of stability across releases.
> > The array could contain various attributes with information about the 
> > internal
> > representation of the variable. I don't believe this can be done in an
> > extension because the implementation details are hidden by the API.
> 
> I'm OK with this, a long as the doc is VERY clear that the contents of
> the array can change from release to release and is there mainly for
> debugging purposes.
> 
> Or you could add more info to the existing debugging adump() function
> and use that.

I'm imagining something that might also be useful for debugging other types of
issues. For example, if it's a number, how is it actually represented
internally -- as a float, mpfr_t, or mpz_t? So I think it makes sense either to
add a "vdump()" debugging function or make this accessible through typeof().
That being said, I'm not chomping at the bit to implement this and am wondering
whether anybody else has any interest in this. I don't want to do it if 
nobody else thinks it might be useful.

Regards,
Andy