> Oh, maybe I didn't express myself well enough. The line
>
> map(f, l) == map!(f, copy l)
>
> is an implementation detail. It's a good default, but if the context
> (speed or violation of some conventions) give rise to another
> implementation that doesn't build on map!, then one should consider
> reimplementing map inside the respective domain %.
Yes, you are right. That's implementation detail.
'map' doesn't have to depend on 'copy' at all, basicly:
map(f, l) == cons(f first l, map(f, rest l))
(then rewrite to avoids recursion)
So about 'copy', from Aggregate:
copy : % -> %
++ copy(u) returns a top-level (non-recursive) copy of u.
What does that mean for AssociationListAggregate?
If 'map' doesn't use 'copy', then 'copy' of AssociationListAggregate
'returns a top-level (non-recursive) copy' seems fine to me.
This 'copy' is good enough for non-destructive usage.
On the other hand, 'ALAGG has Dictionary', and in Dictionary:
++ This category models the usual notion of dictionary which involves
++ large amounts of data where copying is impractical.
++ Principal operations are thus destructive (non-copying) ones.
BTW, 'copy' of Record seems wrong:
(1) -> T ==> Record(a:List Integer)
Type: Void
(2) -> x : T := [[1]]
(2) [a = [1]]
Type: Record(a: List(Integer))
(3) -> y := copy x
(3) [a = [1]]
Type: Record(a: List(Integer))
(4) -> x.a.1 := 2
(4) 2
Type: PositiveInteger
(5) -> x
(5) [a = [2]]
Type: Record(a: List(Integer))
(6) -> y
(6) [a = [2]]
Type: Record(a: List(Integer))
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
