login  home  contents  what's new  discussion  bug reports     help  links  subscribe  changes  refresh  edit

Edit detail for #208 interpret(x::InputFor)=x is broken for functions and types revision 3 of 4

1 2 3 4
Editor: gdr
Time: 2008/05/19 20:16:44 GMT-7
Note:

added:

From gdr Mon May 19 20:16:44 -0700 2008
From: gdr
Date: Mon, 19 May 2008 20:16:44 -0700
Subject: 
Message-ID: <20080519201644-0700@axiom-wiki.newsynthesis.org>

This is a problem with AXIOMs not making their minds about whether
a map should be treated as a value in its own, or whether it is an expression
that needs further evaluation to yield a value.
The proper fix is to have all user defined maps treated as
values in their owns -- e.g. their representation in the
interpreter environment should be wrapped.  However, that requires a 
more extensive patch to implement.  But, that is the right thing to do.

Submitted by : (unknown) at: 2007-11-17T22:08:45-08:00 (17 years ago)
Name :
Axiom Version :
Category : Severity : Status :
Optional subject :  
Optional comment :

The coersion to InputForm? produces a lispy representation for most types. E.g.

axiom
)set output tex off
axiom
)set output algebra on

axiom
p:POLY INT:=x^2+1
2 (1) x + 1
Type: Polynomial(Integer)
axiom
pSex:=p::InputForm
(2) (+ (^ x 2) 1)
Type: InputForm
axiom
p1:=interpret(pSex)
2 (3) x + 1
Type: Polynomial(Integer)

But this fails for functions

axiom
f:INT->INT
Type: Void
axiom
f(x) == x^2+1
Type: Void
axiom
-- force compile
f(2)
axiom
Compiling function f with type Integer -> Integer 
(6) 5
Type: PositiveInteger
axiom
fSex:=f::InputForm
(7) (coerceOrCroak (CONS '(Mapping (Integer) (Integer)) (wrap (MAP (#1 + (^ #1 2) 1)))) '(InputForm) 'noMapName)
Type: InputForm

So far so good, but

axiom
f1:=interpret(fSex)
Cannot convert from type (Integer -> Integer) to InputForm for value theMap(MAP)

Category: Aldor Library Compiler => Axiom Library

This is a problem with AXIOMs? not making their minds about whether a map should be treated as a value in its own, or whether it is an expression that needs further evaluation to yield a value. The proper fix is to have all user defined maps treated as values in their owns -- e.g. their representation in the interpreter environment should be wrapped. However, that requires a more extensive patch to implement. But, that is the right thing to do.