On 31 October 2016 at 12:21, Waldek Hebisch <hebi...@math.uni.wroc.pl> wrote:
> Bill Page wrote:
>> >
>> > But I also wonder why 'typeOf(Integer)' is 'Type', i.e. that specific
>> > category 'Type'. Why not 'Ring' or some other category that 'Integer'
>> > satisfies?
>>
>> Actually, thinking about this again, if 'typeOf' can return a category
>> as the type of some domain why doesn't 'typeOf(Integer)' return
>> exactly the category that appears to the right of the : when 'Integer'
>> is defined?
>>
>> Integer : Join(IntegerNumberSystem, LinearlyExplicitOver Integer,
>> PolynomialFactorizationExplicit, ConvertibleTo String,
>> OpenMath, Canonical, canonicalsClosed) with
>> random : % -> %
>> ++ random(n) returns a random integer from 0 to \spad{n-1}.
>>
>> Yes, this might be a bit awkward except perhaps when used programmaticaly as
>> in
>>
>> (1) -> Float has typeOf(Integer)
>>
>> (1) true
>>
>> where the current result seems of little value.
>
> Well, serious implementation of 'typeOf' would do this. As
> you noted printing such types may be awkward. Concerning
> current implementation: interpreter knows almost nothing about
> categories so typically it considers all domains to be just of
> category 'Type'. This should be fixed in the future.
Excellent.
> However, there are a lot of things to fix. That is why I asked
> about uses: if there are important uses, then priority of problem
> would raise. And if full fix requires too much effort sometimes
> we can implement enough functionality to allow desired use.
>
I understand that resources are limited and setting priorities is
unavoidable. But one difficulty with systems like FriCAS/Axiom is that
usage is deliberately constrained by design (e.g. the rigid but
rigorous static types both built-in and defined in the FriCAS
library). I think most successful users of FriCAS are comfortable with
the idea of searching for the "one best way" of expressing a
particular solution within these constraints. This design however
should be informed by the most general self-consistent theory possible
otherwise the constraints simply seem ad hoc and attempts to approach
a problem that way in FriCAS will more often be abandoned rather than
expressed as a new requirement or missing functionality.
Many years ago when I first read the documentation that Kurt has
quoted and started trying things such as those expressed in this
thread I worried that there was something wrong buried deep inside the
design of Axiom. Later it seemed that these problems really had very
little impact on what I actually normally wanted to do with Axiom. But
it made me wonder how many people may have been prematurely turned-off
by such things before they had a good chance to really appreciate what
Axiom could do. Hence FriCAS/Axiom has a much smaller user/developer
base than say somewhat more obscure and esoteric systems like Haskell
or even Ocaml and the comparatively much wider appeal of less
rigorous systems like Maxima and Sage.
So personally I still give this a high priority in spite of the fact
that I cannot propose an indisputable use-case.
--
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 fricas-devel+unsubscr...@googlegroups.com.
To post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
