[Axiom-developer] Re: .spad, .input, .as and autocoercion

[William Sit]

Ralf Hemmecke wrote:

> On 08/16/2007 12:11 PM, William Sit wrote:
> > ...  why aren't you and Ralf in favor of
> > improving the compiler so that the compiler can be equally helpful?
>
> Because I believe we will end up in something like Maple or Mathematica.
> I constantly hear people complain that they don't understand what
> Mathematica is actually doing internally.

That is because neither Maple nor Mathematica is open source. Making the
compiler more helpful will not turn Axiom into either of them. Why do you
favor downgrading the interpreter instead of upgrading the compiler? We
already agree that there should be one language. All I ask is that there be
help in programming the language. I did not ask to make the language
"fuzzy".

> > Why should the human programmer be forced to manually perform what
> > the interpreter is doing so well (and most likely can be even
> > improved)?
>
> You say it. The interpretation of your source code depends on the
> capabilities of the "interpreter". That is like saying
>
> simplify(someexpression)
>
> in Maple which doen't simplify anything in Maple6 but does something in
> Maple11.

I don't follow what you are pointing at. You seem to be supporting my
thesis: When there is only one language, there will be NO interpreter, only
options to accept suggested selection or not in the user interface
(preferrably an editor, emacs if you like). Newer versions (as Maple6 vs
Maple11) will only improve the accuracy of the help.

> > Currently, to translate from interpreter language to compiler
> > language, one needs a combination of ")show," ")display," ")set mess
> > bottom on," ")set message auto on," and hyperdoc searches to identify
> > packages and coercions. This process is repeated every time there is
> > a compiler complaint. This is time that could be spent for
> > documentation instead.
>
> If you simply make your experimental code into something that SPAD
> understands than you are missing the *design* phase.

What has this discussion to do with the design phase? Are you implying that
experimental code need no design before hand? That would be a terrible way
to approach Axiom programming. (Recall the lengthy discussion we had for the
Units and Dimension.)

> I believe that it is good to have a system that let's you experiment
> with objects and lets you invent new algorithms. But once you have an
> idea how that should actually work you should make the input/output
> specification clear. That for example will most probably rule out the
> use of "Expression Integer" in library code. There will be most
> certainly be domains that are more specific for the implementation of
> the algorithm that you have just invented.

The way I program in Spad, the .input file is very close to my final Spad
code, except of course, the changes that is forced because of
incompatibility. Here I am referring to mainly packages or algorithms, not
domain or category constructors, which unfortunately, the Axiom interpreter
would not understand. Constructing a skeleton of category and domain is
fairly easy: you need as you say get the input/output and data structure,
and the exports. Implementation of packages is the harder part and can be
"experimented" using .input files.

I don't agree that Expression Integer should not be in library code. If what
you suggest is taken at face value, then Expression domain constructor
simply should be removed. As with any algebra domain, there are implicit
restrictions on their use and when not abused, they work as intended. Of
course, not all restrictions are enforced or enforceable currently. All
computer software are based on protocols.

> > Documentation is constantly being added and revised. I don't consider
> >  documentation "pain," because it is necessary. I do consider
> > spending time to rewrite interpreter code into compiler code a waste
> > of time and therefore "pain".
>
> Being also a mathematician, I clearly understand your point. But
> Computer Algebra deals with constructive mathematics. And there is a lot
> more to tell a stupid computer. If some day we arrive at a system that
> can translate fuzzy experimental code into nicely specified and
> efficient library code, then I am on your side. But this is probably a
> big research topic.

I am not suggesting fuzzy code (experimental or not).

> The Aldor compiler sometimes tries to help you in such a way. There are
> messages like
>
> No function foo: () -> Integer is available but could be used if
> imported from SomeFooType.
>
> I certainly have nothing against the compiler listing all the options at
> the place of failure. I know what a pain it was to rewrite .input files
> into .spad files. That was one of the reasons I stopped writing .input
> files in Axiom. Or I should better say, I stopped developing programs
> using .input files.

Of course when you have become an expert in writing in Aldor or Spad, there
is no need to use the interpreter. Do you think it would be easy for a
newcomer to program directly in Spad, with no help on coercion?

> > The three incompatibles (interpreter, Spad compiler, Aldor compiler)
> > are, I believe, the main reasons why the commercial version did not
> > receive wider popularity. This triad of languages becomes confusing
> > to most users, old or new.
>
> I very much agree. But I still don't want autocoercion. The user
> interface (i.e. type guessing and such -- which corresponds to BNatural)
> should be programmed in a library and should not be part of the
> Aldor/SPAD language.

The fact that you don't want autocoercion should not imply that autocoercion
should be denied others. Providing help does not mean the language is
changed. How to program the help is an implementation issue, not a design
principle.

William