[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] Re: [Axiom-mail] RE: AXIOM / TeXmacs problems (bugs?)

From: David MENTRE
Subject: [Axiom-developer] Re: [Axiom-mail] RE: AXIOM / TeXmacs problems (bugs?)
Date: Mon, 08 Dec 2003 20:00:37 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux)

[ Continuing on axiom-developer... ]


"Bill Page" <address@hidden> writes:

> There are differences however even in the semantics when
> you write library routines that are intended to be compiled.
> For example you must provide much more explicit type
> information since you can no longer depend on the interpreter's
> heuristics for type inference. I am not sure how ambitious
> one should be in attempting to resolve such differences.

Another approach might to use only a compiler, the "interpreter" just
feeding input to the compiler and displaying its output. This is the
approach followed in the Objective Caml language. 

Such a design would raise the issue of having a good type inference
algorithm that would allow (1) a light syntax (an absolut necessity for
the interactive mode) and (2) would be, at the same time, a unique, well
defined and correct type inference. From the few pages I have read in
the Jenks & Sutor book, the "label" type inference (or "record" type
inference) as found in the Objective Caml language and used for the
typing of objects (as in object-oriented) might be sufficient. But
clearly more work would be necessary to have a light syntax in
interactive mode[1].


[1] In short, in ML like languages, the type of objects is deduced from
    the name of the operator (e.g. '+' has '(INT, INT) -> INT'
    signature, using Axiom notation). In Axiom, it appears to me that
    typing is more object-oriented like, in the same way as SmallTalk or
    C++ with overloading: the type of objects determines the type of
    operation to apply. One might envision a typing system where you
    have several operators ('+int' for (INT, INT) -> INT, '+poly' for
    (POLY, POLY) -> POLY) (thus you can use ML-like type inference) but
    hide those several operators with some "hints" from the typing of
    previous objects in interactive mode (e.g. x is a POLY, so the '+'
    in "x+3" means "use the '+poly'"). I don't know yet if this idea is
    just smoke in my brain or a real good idea. :)
David MENTRE <address@hidden> --

reply via email to

[Prev in Thread] Current Thread [Next in Thread]