On 12/06/2008 02:51 AM, Bill Page wrote:
> 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.
CatOfR was meant to be the exact category expression that is used in the
definition of R.
>> 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}.
I am sorry, but that is exactly *not* what I had in mind. To make it
more concrete, replace
R: CatOfR == add ...
everywhere with
SparseUnivariatePolynomial(T:Ring): UnivariatePolynomialCategory(T) with
outputForm : (%,OutputForm) -> OutputForm
fmecg: (%,NonNegativeInteger,T,%) -> %
== PolynomialRing(T,NonNegativeInteger)
add
...
i.e. with the concrete definition of a domain.
As you probably realize here.
UnivariatePolynomialCategory(T) with ...
is certainly not a "one-element category".
> 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.
Also if I take the correction of that paragraph in your other mail
http://groups.google.com/group/fricas-devel/msg/7e29d803d32f549b
into account, I really mean "known at "compile time". I speak about that
"SubsetCategory" appearing in a .spad file. There you always know about
the type of R statically. If you think otherwise, you should give a
concrete example of an identifier R that appears in a .spad file and
from which you wouldn't know its type.
> 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?
Because it is not needed. What you want is to compute with category
expression. That is not really a such a bad idea, but leads to problems
as you certainly know from
http://axiom-portal.newsynthesis.org/refs/articles/define.pdf
in particular (see page 5) when the CatOfR from above is
CatOfR: Category ==
if random() then
with {a: SingleInteger}
else
with {a: Float}
>> ================
>> 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?
Basically, yes. Do you see a problem with that? When you are going to
program Foo, you are not interested in the exact category of R. All you
need is certain properties that R must have. In
Foo(R: CatOfR, S: Join(Monoid, CatOfR)): ...
CatOfR is actually the wrong name. I should better have chosen
"FoosRequirementForR". The actual category is really not interesting.
All that Foo cares about is that its parameter has to fulfil a certain
set of properties which is encoded in the type of the parameter
specification. I hope I could make that now clear enough.
>> I am still for removing SubsetCategory (and actually also SubDomain).
> 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. :-(
I only heard Waldek saying that SubsetCategory causes 30% of all the
compile time. There should be a better implementation of the concepts
SubsetCategory and SubDomain anyway. I think they are better started
from scratch if someone sees need for having them. My experience with
Aldor where these concepts do not exist, is, that I never felt the need
to reintroduce them. Just let's take a pragmatic approach here and have
faster compile time now.
I'll start testing my changes locally and will propose a patch
(hopefully this weekend).
Ralf
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
