On Thu, Aug 28, 2008 at 11:24 AM, Waldek Hebisch
<[EMAIL PROTECTED]> wrote:
>
> 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.
Well, it sort of "half-works". The problem is shown here:
http://axiom-wiki.newsynthesis.org/SandBoxAbelianDuck
The compiler fails to compile:
Identity(u:Symbol,m:Symbol):Category == Commutative(m) with
u: () -> % ++ unit
But writing it this way (passing a constant) does work:
Identity(u:Symbol):Category == Commutative(_*) with
u: () -> % ++ unit
Apparently the problem has something to do with parameters in
categories. Is it possible that this error has nothing to do with this
definition of Commutative but perhaps affects all dependent types more
generally?
> 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)
>
In principle it should be easy to give reasonable operational
semantics for declarations similar to the way Symbol is used in the
interpreter. E.g.
(1) -> f:Symbol
Type: Void
(2) -> f+1
(2) f + 1
Type: Polynomial Integer
(3) -> f:=g
(3) g
Type: Symbol
(4) -> f+1
(4) g + 1
Type: Polynomial Integer
--------
In other words, if symbol has no assigned value then it evaluates to
itself. But if it's value is another symbol, then that symbol is used.
So I might reasonably expect that
f:Integer
would be evaluated as declaring 'g' to be of type Integer:
g:Integer
and
f(x)==3
would be evaluated as defining the function g(x)
g x == 3
Type: FunctionCalled g
Except that is not what happens now in the interpreter.
> 3) Assuming that Commutative(_*) has proper support in the
> Spad compiler changing CommutativeStar to Commutative(_*)
> is trivial.
>
Agreed.
>> > - 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.
>
Do you mean there is a difference if I write
Join(shallowlyMutable,Foo)
and
Join(Foo, shallyMutable)?
Why would the "interpreter think that foo came from shallowlyMutable"
if shallowlyMutable does not export 'foo'?
> There are various possible fixes, and it may take some
> time to implement one of them, so it looked reasonable
> for me to hack around this problem to go forward.
>
I wonder if it is not more important to fix other problems first that
prevent a clean solution to this problem without hacks?
Of course these are just my personal comments and should not prevent
you from proceeding with these planned changes if you still think it
is valuable.
Regards,
Bill Page.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
