Bill Page wrote:
>
> Waldek,
>
> On Wed, Aug 27, 2008 at 3:37 PM, you wrote:
> >
> > I have now a patch which removes attributes and replaces them
> > by empty categories.
>
> I support this change.
>
> > Some remarks:
> > - commutative("*") is strange beast, to avoid problems with
> > meaning and type of the argument I replaced it by
> > CommutativeStar category. Once we have a solution to Monoid
> > problem we can change this, by currently having parameter to
> > commutative looks like useless complication
>
> I disagree. I think defining commutative this way makes very good
> sense:
>
> Commutative(op:Symbol):Category == with op:(%,%)->%
>
> then any place that attribute commutative("*") is used we should just remove
> the
>
> *:(%,%)->%
>
> export and replace the attribute with the category Commutative("*").
>
> Also as I noted in another thread, passing a parameter like this is
> one way to solve the "Monoid problem".
>
1) IIRC you wrote that this form currently does not really work.
2) This form is also poorly defined semantically (and typing
rules are unclear). For example, Spad compiler accepts:
)abbrev category ATCOMM Commutative
Commutative(op:SExpression):Category == with op:(%,%)->%
and then you can "use" things like:
Commutative([1::SEX, 2::SEX]::SEX)
3) Assuming that Commutative(_*) has proper support in the
Spad compiler changing CommutativeStar to Commutative(_*)
is trivial.
> > - when I just modified algebra there were some regressions --
> > for example interpreter thought that some functions defined in
> > HomeogeneousAggregate are defined in shallowlyMutable
> > category. To avoid them I had to hard-code knowledge about
> > categories which replaced attributes in the interpreter.
>
> This does not seem desirable to me. I do not understand why the
> interpreter has problems with these new categories. It seems to me
> that the semantics of attributes are (or at least should be) exactly
> the same as for categories. If this hard-coded knowledge is necessary
> to work around some bug, then perhaps it would be better to fix the
> bug. No?
>
>From interpreter point of view semantics of attributes and categories
is quite different. Namely, interpreter cares where an operation
is defined. Given modemap like:
(|foo| (*1 *1 *1)
(AND (|has| *1 (ATTRIBUTE |shallowlyMutable|))
(|ofCategory| *1 |Foo|)))
it is clear that foo came from Foo. But given
(|foo| (*1 *1 *1)
(AND (|ofCategory| *1 |shallowlyMutable|)
(|ofCategory| *1 |Foo|)))
interpreter thinks that foo came from shallowlyMutable.
Note: *1 (the first entry on the list) is constructor where the
operation is defined.
There are various possible fixes, and it may take some
time to implement one of them, so it looked reasonable for
me to hack arond this problem to go forward.
--
Waldek Hebisch
[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
