Hi, I'm trying to modify bundles that were previously put into an array (of bundles): <hansl> bundles bs = array(1) bundle singleb # try to stuff into the array: bs[1] = singleb # works # and modify: scalar bs[1].num = 3 # fails "not acceptable with arrays" bs[1].num = 2 # fails "no formula in genr" </hansl> So is it simply the case that every bundle must be "finalized" before putting into a bundles array and then becomes immutable by design, or is there a bug?

Am 06.01.2017 um 22:44 schrieb Allin Cottrell: > On Fri, 6 Jan 2017, Sven Schreiber wrote: >> # and modify: >> scalar bs[1].num = 3 # fails "not acceptable with arrays" >> bs[1].num = 2 # fails "no formula in genr" >> </hansl> >> >> So is it simply the case that every bundle must be "finalized" before >> putting into a bundles array and then becomes immutable by design, or >> is there a bug? > > There's an unimplemented feature ;-) No, we have not decided that array > members should be immutable, but neither do we have the apparatus in > place to support modifications of the sort you describe. In fact I don't necessarily think this is a high priority. Maybe the best short-term course of action would be to simply say what the status-quo is: if you want to build an array of bundles, you first have to make up the individual bundle, and then stuff it into or append it to the array... > We've been here before: it's difficult to stack up "membership-of" > relationships, the way our parser is currently structured. This applies > particularly to the left-hand side of "genr" expressions but also to a > degree on the right. Note that > > eval bs[1].num > > doesn't work either. Yeah, that is a more serious problem. > to fix this in a general way. I'll try to get this done before the > Athens conference, maybe sooner. Again, is this really that pressing? I mean, who except myself is using this anyway...?