On Mon, 11 Feb 2008, Bill Page wrote: | > But I do agree that it's a possibility, although it looks quite | > complicated to me: it would mean to modify the representation | > of Symbol ... but I wouldn't even know in what way - how | > would you like to represent a symbol, which should display | > as, say "E\alpha"? | > | | As I said before, allowing arbitrary strings of symbols to be a member | of Symbol could be very similar to how subscripts are represented. | | (5) -> script(alpha,[[i,j],[k,l,m],[a],[b,c]])::OUTFORM::SEX | | (5) (*02312alpha i j k l m a b c) | Type: SExpression
Am I the only one to be bothered by this purely syntactic encoding of something that could have semantics content? I've always been annoyed that the parser would decide to encore subscript, before semantics processing starts. | (6) -> argscript(A,[x,y])::OUTFORM::SEX | | (6) (*20A x y) | Type: SExpression | | Refer to the source code for the internal representation of Symbol. It | seems that Symbol is written a rather "old" style that presumes a Lisp | s-expression representation. For example: | | script(sy: %, sc: Scripts) == | scripted? sy => error "Cannot add scripts to a scripted symbol" | (concat(concat(syprefix sc, string name sy)::%::OutputForm, | syscripts sc)) pretend % | | scripted? sy == | not ATOM(sy)$Lisp | | So any s-expression that is not a Lisp atom is currently considered | "subscripted". The prefix on the internal name, e.g. "*02312alpha" | provides information about the type of subscripts. This obviously | would have to be generalized to admit other types of constructions for | symbols. I think that in principle this should not be too difficult | although I guess there could be complications if assumptions about the | representation of Symbol is spread outside of the Symbol domain. (It | should not be.) -- Gaby ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ open-axiom-devel mailing list open-axiom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
