"Bill Page" <[EMAIL PROTECTED]> writes:
| On Mon, May 12, 2008 at 3:08 PM, Gabriel Dos Reis wrote:
|
| > ... Indeed, the compiler seems to eventually resolve to the
| > right symbol. Consequently, there must be a specification (e.g.
| > an algorithm) that systematically work without producing the
| > above diagnostics. In my view, the context should help decide
| > which interpretation of a symbol is desired, but that is not so
| > simple because when faced with
| >
| > print pol.degree
| >
| > it is not always immediately clear whether '.degree' refers to a
| > real function or a field of record.
| >
| > For the moment, I'm going to downgrade the above diagnostic to
| > `warning'. And I would appreciate to know what people think.
| >
|
| I am not able to say whether ignoring these "semantic errors" is a
| good thing or not, but downgrading the message to a warning makes
| sense to me since apparently that is how the compiler actually treats
| it now anyway ...
In fact, I'm not propositing to ignore those `semantic errors'. It
just happens that the compiler consistently chooses literals over
anything else (and this is documented in the Axiom book, but my copy
is at home and I'm at office right now) and if that choice is not
good, other phases of the compilation correct that -- this
particularly happens through compUniquely. I suspect that there is
an algorithm that will make the `right choice' all the right without
having to produce the `semantic errors'.
Furthermore there is an *actual bug* in the compiler where a `semantic
error' is supposed to prevent the compiler from actually producing an
object code (and subsequently modify the module being compiled). It
is that bug I was aiming to fix in the first place (the fix is
simple), but I needed to fix the `semantics errors' in the algebra.
The only real semantic error is the import of `RatODETools' which does
not exist.
| But I do have one side comment: As I have argued elsewhere, I think
| that semantically there is no good reason to distinguish a "real
| function" from a "field of a record".
The compiler does not make such a distinction. See below.
| In fact a "field" is just a
| projection function when the record is viewed as a (categorical)
| product. There should be no separate name space. E.g.
|
| a: Record(a:A, b;B) -> A
| b: Record(a:A, b;B) -> B
|
| The built-in Record constructor should provide such functions.
This is what they do. Additionally they go on making `a' and `b'
literals, to indicate that they are field. I suspect this is a left
over from old days. Also I suspect it is designed as a workaround
the fact one cannot have a function name that is both exported and
local. Fields (or more specifically the function they define) are
always exported. So, if you look at the case of the MoebiusTransform
(before my commit of last night), you will see that that domain
defines local functions that bear the same names of the record fields
they are surrogate for. Semantically, there is no ambiguity as you
can see from the source code, and the generated Lisp. However, it is
one of the cases where you have field names clashing with local
functions.
Rep := Record(a: F,b: F,c: F,d: F)
moebius(aa,bb,cc,dd) == [aa,bb,cc,dd]
a(t:%):F == t.a
b(t:%):F == t.b
c(t:%):F == t.c
d(t:%):F == t.d
(this may read an infinite recursion -- but OpenAxiom is carefull
enough to retain the intended semantics). It is a wart.
-- Gaby
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
