# convert/identifier

July 05 2012 by
false
Maple

1

This post in reply to the Comment, Re: But it is doable!

Here is a hacked-up and short convert/identifier procedure.

The shortness of the procedure should is a hint that it's not super robust. But it can be handy, in some simple display situations.

If I had made into a single procedure (named G, or whatever) then I could have declared its first parameter as x::uneval and thus avoided the need for placing single-right (uneval) quotes around certain examples. But for fun I wanted it to be an extension of convert. And while I could code special-evaluation rules on my convert extension I suppose that there no point in doing so since convert itself doesn't have such rules.

For the first two examples below I also typed in the equivalent expressions in 2D Math input mode, and then used the right-click context-menu to convert to Atomic Identifier. Some simple items come out the same, while some other come out with a different underlying structure and display.

 > restart:
 > convert/identifier:=proc(x)    cat(#,convert(convert(:-Typesetting:-Typeset(x),global),name)); end proc:
 > convert( 'sqrt(4)', identifier);

 > eval(value(%)); lprint(%);

#msqrt(mn("4"))

 >

 > lprint(%);

#msqrt(mn("4"))

 > convert( 'int(BesselJ(0,Pi*sqrt(t)),t)', identifier);

 > eval(value(%)); #lprint(%);

 >

 > #lprint(%);
 > convert( Vector[row](['Zeta(0.5)', a.b.c, 'limit(sin(x)/x,x=0)', q*s*t]), identifier);

 > eval(value(%)); #lprint(%);

As it stands this hack may be useful in a pinch for demos and purely visual effect, but unless it's robustified then it won't allow you to programmatically generate atomic names which match and inter-operate computationally with those from the context-menu conversion. Identifiers (names) with similar typeset appearance still have to match exactly if they are to be properly compared, added, subtracted with each other.

Extra points for commenting that the round-brackets (eg. in function-application) are displayed as black while the rest is in blue by default, if you have a workaround.  That also happens when using the usual context-menu driven convert-to-atomic-identifier of the Standard GUI.

Extra points for noticing that function names like sin are italicized and not in an upright font, if you have a workaround. How to discern which instances of fontstyle="normal" should be removed?

Points off for commenting that this whole hack doesn't provide anything new or extra for getting around automatic simplification.  :)

This is a one-liner hack. But maybe together we could turn it into something that closely matched what the context-menu generates.

acer