On Fri, 6 Jan 2017, Sven Schreiber wrote:
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...?
I think that many script-writers would use this sort of thing if was
expected to work -- and it really ought to work. Your exceptionality
is that you keep trying it, and pointing out that it doesn't work
;-)
Allin