Bill Page <bill.page@...> writes:
| On Sun, Jul 8, 2012 at 1:43 AM, Ralf Hemmecke <ralf@...> wrote:
| > ...
| >> It does not seem odd to me that Record would export SetCategory if
| >> all it's components satisfy SetCategory.
| > Well, from a mathematical point of view, that's certainly something
| > one would wish, but I've a probalem with that. Record is a builtin
| > constructor, SetCategory is not. Or in other words. Record is language
| > defined, SetCategory is not. For that reason, in the specification of
| > Record, there cannot be any SetCategory mentioned, not even
| > conditionally. If there were "extend" in SPAD, the issue would be
| > different. But even in Aldor (with "extend") I had no clue how to write
| > down that if *all* domains that form the record (note that this is not a
| > fixed number) are of type SetCategory, then the record would export
| > SetCategory.
| I see the problem. As far as I can see this issue does not only affect
| Record but also at least Union and Mapping as well. I have a lot of
| examples where it would be nice to be able to "extend" these too.
I believe that in OpenAxiom, these builtin types satisfy SetCategory
| I agree that Record is "built-in" in the sense that the compiler has
| some hard coded knowledge about the constructor but in principle I
| don't think that should preclude it's elaboration in the library. If
| the SPAD language is not powerful enough to specify the behaviour of a
| constructor like Record, then perhaps it needs to be extended
| slightly. In particular I think SPAD does not have a separate type
| associated with the 'tag:type' construct while Aldor does in principle
| have more general support for this. Personally I would prefer that
| they not be treated as tags at all but rather functions.
| >> The main issue in fact is equality so maybe BasicType would be more
| >> accurate.
| > Maybe, but a record should just stay what it is: a data structure. I
| > wouldn't expect it to export anything except constructors and access
| > methods.
| >> Does it make sense to have a HashTable with entries that do not
| >> support equality?
| > Why not? I think we had this issue some time ago. To make it clear: we have
| > Table(Key, Entry) and I am speaking about loosening the conditions for
| > Entry, not for Key.
| OK, thanks for the clarification.
| 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 fricas-devel@....
| To unsubscribe from this group, send email to fricas-devel+unsubscribe@....
| For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.