@Carl Love 

The meaning of the empty exponent seems to depend on the parser. It is "fine" in 1-D but an error in 2-D:

> 1^();# in the CLI
                                       ()
                                      1

1^()
Error, invalid power
...

@acer 

Yes, it may be a tangent discussion, but worthwhile nevertheless, I think, as this subject is barely documented. A brief comment in the Programming Guide, Chapter 6 Procedures > 6.5 The procedure Body > Options > The builtin option, and not much more. And I agree that it is interesting to know how the kernel/non-kernel dispatch works. Moreover, I would say that it should be described properly in the help pages.

About commands Vector, Matrix being fully builtin, I wonder whether the problem would be maintainance. E.g. the procedure Matrix is currently quite long (about 200 lines), and debugging it in the kernel would be more difficult.

@acer 

Actually, `<|>` is partially builtin, as described by someone of the kernel group, for those cases (sin, etc) where part of the code is in the kernel and part in the library. Hence the difference in type with full builtin:

> type(`<|>`,builtin);
                                     false
> type(eval,builtin);
                                      true

I understand that this setup is typically kind of overload, with hfloat type arguments, say, handled by the kernel part. This status holds at least since Maple 11.

Could you elaborate why using NOSQL object database would help preventing out of memory?

I observe an empty plot window, when pressing the brown button, both in Maple 17 and 18 on Linux 32-bit. On general terms, I would not be surprised to see maplets break down as the development on the Maplet facility has been frozen for about six years.

@ecterrab 

Exactly, I get 0 with 1D and doted g with 2D. I was not aware of this difference! Another one for the Babel's collection...

@rlopez 

With your commands above, the output for diff(g(t),t) is g with an overdot, but the output that I get of diff(g,t) is 0. So, some detail seems missing.

@Carl Love 

Here, Sandra said about the decision not to support the preprocessor directives.

@taro 

The same with specop. It works fine as long as the type name is not overloaded:

> type(x+y, specop(name,`+`));
                                      true
> with(VectorCalculus):
> type(x+y, specop(name,`+`));
                                     false

@Andriy 

I agree, there is a design problem here. Several packages export procedures named `+`, `*`, etc, which may overload top level type names. This is another unfortunate consequence of using the same names for procedures and types (as the need to "neutralize" them by unevaluation quotes shown before).

@taro 

You can reconstruct c as follows:

> c:=a<b;
                                   c := a < b
> op(0,c)(op(c));
                                     a < b

What is missing for ('`*`')(a,b) to become a*b is one evaluation level removing the unevaluation quotes, like:

> '`*`'(a,b);
                                    *(a, b)
> %;
                                      a b

Yes, convert(...,`*`) has a different application domain than convert(...,lessthan). The latter admits only relations, as stated in ?convert,equality, or looking at its code:

> showstat(`convert/lessthan`);
`convert/lessthan` := proc(x)
   1   if not type(x,relation) then
   2     error "argument must be of type relation"
       else
   3     op(1,x) < op(2,x)
       end if
end proc

Note, by the way, that the former is builtin, and lessthan is not a type. So, yes, a counterpart conversion seems missing. But convert is extensible, so that a such procedure could be written, like:

> `convert/<`:=proc(x)
> `<`(op(x));
> end proc:
> 
> convert([a,b],`<`);
                                     a < b

@Carl Love 

In this regards:

> type(x+y,function);
                                     false
> type('`+`'(x,y),function);
                                      true
> type(x+y, specfunc(name, '`+`'));
                                     false

@PatrickT 

Quite interesting, this thread contained a comment of mine that has been removed, but Patrick's reference to it still remains...

@acer 

I agree. What I say is that Maplesoft is currently involved in the development of Maple IDE (originally, yes, it was fully third party). Consequently it has responsability on this bug. May be that this case shows a problem at its testing stages.

@acer 

Here, Laurent has stated:

Together with our partner DigiArea Inc., we have created a modern development environment on top of the popular Eclipse framework....

So, I understand it as also Maplesoft.