Yes, I am proposing that the compiler infer constructors. I don't think partial abbreviation statements (i.e. omitting the actual abbreviation) are necessary. In the compiler if I write:
F(...):Category == ... The compiler knows it is compiling a category, right? If I write: F(...): B == ... with B some category expression, then this is either a domain or a package. Maybe the difference is not so important? But packages do not contain Rep so the compiler knows when it is done parsing whether this is a package or a domain. And in both cases it can construct a default abbreviation. If no )abbrev command involving F was previously given than F would be both the full name of the constructor and its abbreviation. On Fri, Jun 22, 2012 at 12:59 PM, Gabriel Dos Reis <g...@cs.tamu.edu> wrote: > Bill Page <bill.p...@newsynthesis.org> writes: > > | So a reasonable proposal might be to eliminate the restriction on the > | length of the abbreviation > > I did consider this several times in the past; if only I had more than > 24 hours in a day.... > > | and make the "abbreviation" default to the > | full constructor name unless it was previously specified to be > | something different. > > Are you proposing that the compiler infers constructors, or that users > be allowed to partially specify abbreviation statement? > > -- Gaby > > -- > 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-de...@googlegroups.com. > To unsubscribe from this group, send email to > fricas-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/fricas-devel?hl=en. > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ open-axiom-devel mailing list open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
