|
One set of is how to handle the various type conversions:
- Unicode. Both Amzi and Python support unicode, maybe they'll
play nicely, maybe not. Haven't thought about it at all.
- Amzi has a type 'infinite precision real', without a counterpart
in Python, and Python has 'long integers' (infinite length integers)
without a counterpart in Amzi. Plus Python will at some point have
'rational numbers'. Not sure how that will all work out. Python
also has complex numbers, perhaps they could be automatically converted
to some artfully chosen binary functor structure.
- Coercions: the Python class definition mechanisms allow for extensive
conversions to different numberical types, so that for example if an AmziTerm
term1 contained
a string that represented a floating point number, then
float(term1) could be gotten coerce it to float. Is this a good idea?
(Python itself is not very agressive about this; to read a string as a
float you'd have to stick an eval in.)
Another is the handling of Python calls from Prolog:
- Currently tuple-returns from Python are packed into a list.
Another possibility would be python2/3/4 etc. predicates
dropping the tuple-members straight into variables. Not worth it unless
the overhead of packing tuples into lists turned out to matter, which
seems dubious.
- It's almost certainly not possible to define an extended predicate
in Python (no address for a machine-executable procedure). Maybe Pyrex?
But that would be a differentproject.
And some other bugs/deficiencies
- Reporting of various kinds of errors via exceptions
is rather incomplete and deficient.
- In particular, if there's an error in setting up a call of Python
from Prolog, the clause where this happened isn't reported.
- Floats seem to undergo some drift in the far
decimal places when passed back and forth between
Pythom and Prolog, not sure if anything can be
done about that.
And finally note that thare are quite a number of potential 'engine methods of
convenience' that could be defined in Python, in a Python-extension of the
engine class. Perhaps the C-defined engne should actually the the _AmziEngine,
with a Python file defining AmziEngine and providing more methods implemented
in Python.
|
