Just an FYI, for those interested:

Some years ago I found out that the plotting substructure such as THICKNESS(0.1), with a positive float value less than 1, would cause the GUI to render a line thinner than it would for THICKNESS(0).

At that time pretty much no plotting command would do anything with a supplied option such as, say, thickness=0.1 except  to turn it into the suboptimal THICKNESS(0).

These days some commands (such as plot) will handle an option thickness=0.1 and construct the expected, matching substructure. But there are some commands which still may not, eg. DrawGraph. But the good news is that one can still supply thickness=0 and then substitute a replacement into the structure, as I did in my Answer below.

pl_thick_note.mw

@Mister_Matthew_abc If you can still access the email address linked to your older Mapleprimes account then you ought to be able to reset the password associated with it (sent as a link via email, from the login page, say)

The 5th bullet point of Description section the Help page ?procedure shows the syntax as being of the form,

   description descriptionSequence;

and the Parameters section of that Help-page explains descriptionSequence as a "sequence of strings describing the procedure".

A terminating semicolon is shown in the syntax. The word description is shown in lowercase. The fact that descriptionSequence can be a sequence of one or more strings is mentioned, and a string in Maple is documented by being wrapped in double-quotes.

Maple is a case-sensitive language. Sometimes case is used to distinguish functionality and purpose, eg. int versus Int. Alongside that, having other command names (such as Describe) be accepted case-insensitively would be a generally confusing.

The following example shows that, in both 2D and 1D input modes, the elements of the sequence may each be a string or a name.

Download description_01.mw

So it might be an improvement to document that a terminator is mandatory for each of the optional clauses.
nb.The following may not be valid syntax, despite being unambiguous,

proc(x) description "hey now" end proc;
Error, reserved word `end` unexpected

It might be an improvement to document that the elements of the description sequence may each be strings or names.

@WD0HHU I will repeat some of my points, to address your Reply. Wording is important to understanding the cause of problems.

Explore assemblies looks clunky in part because the Embedded Components and the GUI layout elements (eg. Table) are a bit clunky.

The Explore Library command constructs from those, and the GUI inserts and renders them.

That GUI rendering (alone) dictates the font of the tick marks on a Slider, and their font size, which are the aspects you mentioned. There are additional EC issues, like cross-platform appearance, Slider selection granularity, and (some) key aspects of the Table layout, and others.

@Kitonum Yes, that was one of the points I made in my previous Answer.

I'll move that paragraph from the end to the top of my Answer, in the hope it doesn't get missed.

Sorry, I missed that you also asked about possibly hiding the Slider's tickmark(value) labels(markers).

You can do that in the Explore call like so,

Explore(plot(sin(a*x),gridlines),
        parameters=[[a=-3.0..3.0,showlabels=false]]);

That hides them if you find them too large in font-size, but wouldn't help completely with extra white-space issue that you mentioned.

The syntax idea in the above code snippet is that when you use the longer-form for specifying the Explore parameters, ie,
    Explore(..., parameters=[ [...], [...] ] )
then you can add options specific to each Slider/ComboBox/other-controller within those sublists. See the programmatic Slider constructor Help-page.

You can also right-click on the Sliders in the (already embedded) exploration assembly, and change this Component Property via the popup menu.

Why did you start using this account instead of your old one?

A couple of interesting weaknesses,

Download simp_rad_0x.mw

I'll submit bug reports against those two.

@C_R You also mentioned that Relational Round palette in the recent Question I cited (and for which that palette also contained symbols  `≅`  and  `⊈` under discussion there).

I didn't take the opportunity to make that palette visible at that time, so missed it again.

Vote up.

@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.