@nm 

I think that part of the issue about syntax for inequality is that `<` is a two-argument procedure built in the kernel. See e.g. tracing its execution for this example:

> trace(`<`):
> eq:=1/2 - x + x^2 - y + y^2:
> solve( {eq>0, x>0, x<1, y>0, y<1}, {x,y});
execute <, args = -x, 0
execute <, args = -y, 0
execute <, args = x-1, 0
execute <, args = y-1, 0
execute <, args = -4*x^2-4*y^2+4*x+4*y-2, 0
execute <, args = 0, y
execute <, args = y, 1/2
execute <, args = 0, x
execute <, args = x, 1
execute <, args = 0, x
execute <, args = x, 1/2
execute <, args = 1/2, x
execute <, args = x, 1
execute <, args = 1/2, y
execute <, args = y, 1
execute <, args = 0, x
execute <, args = x, 1
{0 < x, 0 < y, x < 1, y < 1/2}, {y = 1/2, 0 < x, x < 1/2},
    {y = 1/2, 1/2 < x, x < 1}, {0 < x, 1/2 < y, x < 1, y < 1}

On the contrary, Mathematica is mostly implemented on pattern matching, probably making it easier to support an input syntax like 0<x<1.

@Preben Alsholm 

Certainly, a pro of showstat is line numbers. A con is some fields not shown, like options or description.

@Axel Vogt 

Yes, that is something that has to be changed.

@Axel Vogt 

Precisely, because testing and documentation is boring but not trivial, the management should give these subjects the highest priority, hire the best professionals and pay them very well. And there should be an independent quality control department, a subject of an exchange with Jacques time ago.

@JacquesC 

In my experience, such problem is rather frequent. This one is a somewhat similar recent case. I can only guess why. It seems to me that Maplesoft management does not fully understand the importance of information at adding value to the product.

@JacquesC 

Not necessarily, though who knows what might happen within the 34 years horizon? Type constant is a curious case (hack?) where names are "declared" as such by adding them to the sequence value of constants. But that melange is not much useful mathematically. Indeed there is already the `type/boolean_constant`. So, splitting this mechanism into mathematically sensible classes would already make a progress, without the need of any revolution, I think.

@JacquesC 

In my opinion, symbolic constants, as listed in ?constants , is a mixed bag that should have been set appart long time ago: boolean constants, finite real constants, infinity, etc.

@nm 

Well no, that assumption does not hold. Actually, I am calling "visible" for a package those objects that appear in the output of a with statement (for algcurves they are 20). And I am calling "documented" those listed in the help pages (for this package also 20). But note that the objects and numbers do not coincide in general. And certainly, ShowContents shows many more objects. Yet, in the case of modules, you will have to look inside each module (and iterate). And for the case of module based packages, you have those exported procedures that are made not visible and all the private procedures.

Perhaps the output of say, Describe(algcurves) is all that you need.

Sadly, you keep thinking it wrong in term of competition. Threads are valuable as a whole because of their history and their logic. Your inventions, now as "best answer" just spoil their value. Instead of loosing time in such misguided inventions, why don't you devote you time in fixing the real problems of this site, begining with posts that keep disappearing, cases of which I have told you many times here and by private mail.

@Andriy 

Yes, this is how I see it. Picture posts should be avoided as far a possible. Indeed, there are technical problems with this site which puts obstacles for this purpose. For instance, Maple's 2D typeset content (for input and output) can be handled only as pictures (which may render poorly), the same as LaTeX typesetting. Very bad as it is standard nowadays that math oriented sites provide good native LaTeX typesetting, e.g. via MathJax. 

@Carl Love 

Yes, not proper in 1D language but proper in 2D language... Moreover, in Maple 12, as the OP seems to be using, your syntax yields an error because of a bug in the 2D parser (later fixed):

> f:= (x::satisfies(x-> x>0 and x<1))-> x^3 + (1-x)^3;
Error, invalid parameters for inline function

@Andriy 

Certainly not. Much better is preformated input, that you can get from the menu in the GUI editor or using the pre tag in the html editor. It typesets more clear than a picture and can be copied and pasted by any reader. You may find many complaints in this site by different readers about such picture posts. So no, it is no personal issue.

@taro 

If you mean by constant a symbolic constant as Pi, it would not make any difference I think, as e.g. replacing eta with Pi yields the same error message, now for Pi. It occurs because the code of algsubs takes as "variables" all the objects of type name, and Pi is of type name the same as eta. Yes, symbolic constants should not be taken as variables, it sounds like a bug. A deeper problem is that there is no system-wide mechanism "declaring" whether an object of type name stands for a variable or something else. It is largely handled implicitly by context, and this rudimentary approach sometimes fail.

@highsciguy 

My understanding is that this is possible in Mathematica because of its (unified) design, with such commands executing on a single kernel. Maple's current design is basically split into two subsytems. Simplifying, commands run on the C subsytem, while GUI interactions run on the Java subsytem, frequently without a (known) programmatic counterpart. And this is the case of the operations that you would need to perform, I think.

Actual input cannot be copied and pasted from the image you are showing, potentially forcing to retype this input, something that does not make much sense. For this reason a much better posting style is showing input in visible text form. I tend to disregard posts not providing input in such a form.