@C_R 

I think that the most sensible next thing to do would be to clearly define the type of expressions (and subexpressions) that you want handled. I don't think that's been explained yet, without it there's a lot of scope for misinterpretations/mis-implementation/etc.

It's not clear to me yet whether you want lists and sets handled. If you don't handle lists then the reconstructor could get confused by examples whose deconstructed form contains lists (that were allowed to pass through).

It's not clear whether you want type `=` handled (and, if so then you'd need to guard against inappropriate argument flattening of the operand sequence, or else things like,
    (f,g) = s
will become indistinguishable from f = (g,s), etc. If you want to handle equations then wrapping the two arguments (sides) in something seems possible. But you might need a special case for the reconstructor. (Using subsop to shoe-horn in arguments that are bare expression-sequences, to avoid flattening of arguments in a procedure call, can be problematic due to unevaluation.)

It doesn't seem as if type Not(atomic) alone represents those expressions you'd want handled. It gets awkward in the absence of a clear spec.

ps. Yes, the indexing operator `?[]` has a Help-page.

While that "too many levels of recursion" error cannot be caught by either try..catch or the deprecated traperror, it might be of some use that your example might be manipulated if that argument is in trigh form without the I.

For example, you might convert to trigh, sinh, or exp, and then simplify, and then optionally convert to say sin.

[edit] On another note, trying to pinpoint the internal cause of your error, this is an unfortunate side-effect (which might go back to at least Maple 16, 2012).

Clearing the remember table of sin, between that convert and the simplify, helps here.

Note that the sin(I/2*z) in the result from convert is unevaluated. Normally it would evaluate to I*sinh(z/2), but the unevaluated sin call has been added to sin's remember table. Also, `expand/sin` doesn't handle that well.

Download expand_sin_p1.mw

Another fun kind of expression is a list that is indexed by an as-yet-abstract index.

By that I mean that the value of the index is not yet a concrete posint.

I mention this example because it's in vein with the topic under discussion.

I find it interesting because it can be reconstructed using op(0,..) and op(..), but it's another example where the reconstruction is not done by a function call to its own op(0,...) . By that I mean that it's not reconstructed simply via the function call  op(0,expr)( op(expr) ) .

Download list_rep_indexed01.mw

@dharr I find that I am also able to use the entity directly -- without the palette -- in 2D Input by using command-completion on the typed characters simeq   (The symbols shown in the popup are not quite right, but upon insertion of the item matching that name it gets inserted ok.)

I find that I can also add it to my Favorites palette by selecting & dragging from such a successful 2D Input.

An example came up four months ago of another symbol (that could be entered directly as a non-marked-up 1D string like an HTML entity, or entered as an already-marked-up 2D Input symbol by using command-completion or a palettes Favorites item).

@C_R It might be interesting to read why you appear to have focused on type atomic, though you have (now) explained that you want to deal with algebraic expressions.

@janhardo Your modification cannot handle indices which are themselves exression sequences, because it's using only op(1,k) rather than all of op(k) where k is the running index.

So it gets this example wrong,

Download jh_tbl01.mw

A correction couldn't only be a change to use op(k) instead of op(1,k), since the list flattening would make the results ambiguous, unable to distinguish between (f,g)=a and f=(g,a).

Of course, it's also not using the overall approach "listlist"-style to recurse into the list (and/or `=`) representation.

As mentioned, I don't know whether the final goal includes rebulding the original expression. If it does then special-case handling would be need for even expressions like sets and lists.

Not that op(0,e) is not always the same programmatic constructor which would recreate an expression assigned to name e. Consider the following top-down (outside->inside) approach.

G := e -> `if`(e::atomic,e,[op(0,e),map(procname,[op(e)])[]]):

G( [a,b,c] );
                [list, a, b, c]

To rebuild, you could put the special-case handling for sets and lists (which are each an "expression") into either the deconstructor (G) or the reconstructor. By that I mean replacing the word list by `[]`, or set by `{}`, to get an actual constructor.

nb. I am aware that map(procname,[op(e)]) will flatten/conjoin expression-sequences, eg, the operands of, say, (f,g)=(s,t) are unrecoverably merged into a single expression sequence. I wrote earlier that I'd prefer to not flatten the arguments, but the OP's original example has a form which does not guard against it. Wrapping the arguments in lists could make reconstruction cases ambiguous; but wrapping in some special dummy call like, say, __(...) could work.

Moving on, there are also unevaluated expressions, which are still a kind of "expression". They may evaluate to something other than themselves. Would you want to prevent evaluation of such, and if so in the calling of the procedure or in the procedure itself?

Download list_rep_eval01.mw

I've already mentioned automatic simplification, eg. 2*(x+y), q>=p, etc, which cannot be side-stepped with mere unevaluation quotes. In 2D Input mode the distinction is more clear between input syntax that gets treated prior to automatic simplification and the result of parsing to get an expression. Yet another parsing mechanism exists in InertForm for input represented as a string, eg, (for fun),

Download list_rep_InertForm01.mw

It's possible that none of these special cases are important to you, as you might have in mind only preconstructed formulas of expresions that involve arithmetic and "mathematical" function calls of fully evaluated expressions of type algebraic. But I don't yet know whether that's the case.

@janhardo I don't know whether the OP really wants to cover any expression, but you might be interested that there some things which act differently than your code expects:

Download table_vs_op_nops.mw 

It seems like a mistake to me, to have recursive code act on expressions for which the conditional (say, being not type atomic) is not always correctly supported by the ensuing tranformation (using op, nops, etc). Not only could you get an unexpected error (see example above), but in a worse case it might get into an untrappable infinite recursion.

@dharr For me the following works, without assumptions, in versions back to at least Maple 16.02 (2012).

> inttrans[laplace](FresnelS(t), t, p);

     (-1+LommelS2(1,1/2,1/2*p^2/Pi))/Pi

note. It's unclear why the OP tried putting an assumption on a, for an example not containing that name. It might help if the OP uploaded an actual worksheet.

@Roy Hughes 

You should upload (and attach) your worksheet using the green up-arrow in the menubar of the Mapleprimes Reply editor.

@sursumCorda I don't think that you've misunderstood. It seems more a weakness in simplify/constant.

ps. As an aside, this seems mere luck here:
    simplify(convert(f,compose,arcsin,ln));

@nm How's this:

Download ode_solution_remembered_11022026.mw

note: The symmetry methods attempt `odsolve/sym_pat/[F(x),G(y)]` calls `ODEtools/play`, which seems to work with substitutions for x,y by names (`ODEtools/x`, `ODEtools/y`) which lack the assumptions. Then a check for a remembered result in `ODEtools/remember` for `odeadv/high_oder/lin_sym` utilizes the expression with the substituted names, finds details from the earlier call, and it fails out.

@Mac Dude This is just a side comment related to what you've written (as opposed to the OP's issue).

If the GUI (front-end interface) itself locks up while dealing with a particular worksheet then it can be frustrating if killing it would result in lost changes in other open sheets.

The GUI runs in a Java virtual machine (jvm), and by default opening multiple sheets via the desktop icon will result in their all being under that single jvm. Forced closure of that jvm+GUI can then result in all its related open worksheets being closed.

But there is an alternate way to operate. If the GUI is launched with a command option
   -standalone
then the GUI instance will be separate from other instances. When one of the GUI front-end instances crashes hard (without Save offerings) then other sheets in such separate GUI instances won't also get forcibly closed.

On MS-Windows I have two desktop icons for launching the Maple GUI. One is a copy of the other, except that I edit the launching command within it (right-click Properties, IIRC), and add that option (and then rename it something helpful as visual reminder).

So this give me a choice of how to launch. In practice I find that the memory cost of multiple jvms is not prohibitive. (Many years ago the resident memory in the OS was a significant portion of the total available on my machine. These days it's not...)

On Linux I don't use a desktop icon, but launch from a terminal shell with a command (aliased to a single word), eg.
    /usr/local/maple/maple2024.2/bin/maple -s -x -standalone &

There are other variants to this. Eg, I also use the -s option when I want to exclude reading of a personal init file's Maple commands.)

ps. IIRC you might be a Max OSX person. I don't know where the underlying executable call is located under any OSX icon launcher.
pps. Another (slightly odd) thing one can do with separate GUI/jvm is open the very same .mw file more than once (without renaming), separately. Of course, you need to be careful when saving such.
ppps. edit with care

You've asked about this in at least two earlier and separate Question threads.

This is one of them, and plots:-display(seq(...),insequence=true) worked there as well as here.

@sand15 I shall log a full bug report, including a link to your notes (and possibly your .mw files). Thanks.

ps. I didn't write more commentary before about the behaviour (other than only an observation of when the runtime error appeared) because I'm busy these days. But thanks again.