On Fri, Dec 5, 2008 at 11:22 AM, Ralf Hemmecke wrote:
> 1) If I specify
>
> Foo(S: SubsetCategory(Monoid, R): ...
>
> then R and its explicit category must be known outside Foo. Let us
> say the domain R is specified like
>
> R: CatOfR == add ...
> ...
Of course it can also include 'with' and/or 'Join' clauses.
> So the category part of S would be clear. It is
>
> Join(Monoid, CatOfR)
>
> And that is known at compile time. So I could equally well have
> written explicitly
>
> Foo(S: Join(Monoid, CatOfR)): ...
>
'CatOfR' is what I earlier called the "singleton category" of R or
{R}. You say that it is "known at compile time", but as far as I can
see if all we know is R, we have to syntactical means (other than
perhaps SubsetCategory) to tell the compiler that this is the category
that we are talking about. I think that being able to specify this
independently of SubsetCategory is a good idea. If not {R} then why
not make 'CatOf(R)' or something like thatsomehow special?
But recall that Waldek claimed that that it is not really true that
SubsetCategory constructs this Join involving CatOfR. After reviewing
the code again, I agree with Waldek. CatOfR is apparently not needed
here.
> ================
> 2) R is also a parameter of Foo. Then we have
>
> Foo(R: CatOfR, S: SubsetCategory(Monoid, R)): ...
>
> But also here I know the category of R explicitly and could have written
>
> Foo(R: CatOfR, S: Join(Monoid, CatOfR)): ...
>
How do you "know the category of R explicitly"? Do you mean manually
copying the category definition used in the source code of R?
> ...
> But now in some sense Bill might be right. Without the SubDomain
> constructor I don't see any other way to construct subsets of a
> domain. Otherwise SPAD lets me do is to specify a new domain
> that inherits its implementation from some given domain. But since
> (except SubDomain) there is no mechanism to state that two
> domains have the same representation, I am not able to even
> create a domain that would fulfil the SubsetCategory(Monoid, R).
>
Perhaps it is correct to want that 'SubsetCategory(M, R)' be the
category to which the domains 'SubDomain(R,b)' belong and where
'SubsetCategory(M,R)' is special itself inherits the category
structure of M (i.e. is a sub-category of M). I think this would
essentially make the 'Subset' property that is now internal to the
compiler, available directly to the programmer.
I hope I am not saying anything stupid here...
> Sharing the representation and state this by some language constructs
> might be a good idea, but I somehow think this needs more elaboration.
>
I think it would be a good idea to completely and accurately describe
the desired model of sub-domain that we want in FriCAS. I have a
feeling that in spite of how bad it looks, what is implemented in
FriCAS already may not be that far off the mark and might be
salvagable.
> I am still for removing SubsetCategory (and actually also SubDomain).
>
> I have nothing against introducing similar concepts later, but only
> with a clear specification of their meaning and a discussion of their
> pros and cons.
>
As I said, I agree with the need for a clear specification, but I do
not like the strategy of removing something just because we do not
completely understand it. If we were to take this approach more
generally, I think we would end up throwing away many other parts of
Axiom as well. :-(
> Has someone already checked
> http://axiom-wiki.newsynthesis.org/SandBoxSubsetCategoryRemoved ?
>
I have looked at it and I do not see anything wrong with your
proposal. I think we/you should apply this change to a local copy of
FriCAS and run the full regression tests. I think you have given good
reasons as to why we should not expect any regressions in the current
FriCAS library code.
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
-~----------~----~----~----~------~----~------~--~---
