On 05/21/2009 10:04 PM, Waldek Hebisch wrote:
> Ralf Hemmecke wrote:
>> Hello,
>>
>> I seem to be unlucky today... Does somebody have an idea why the
>> following does not work?
>> As a hint... if I remove "(T: BasicType)" from that program, it
>> seemingly works.
> What happens if you rename T to something else? In Lisp code T
> is boolean true, Spad is careful to internally rename T to
> avoid clash with Lisp T, but I am not sure if this is handled
> by the Aldor interface.
Thank you! Thank you! Thank you! Renaming T to X makes the program work.
So it basically means that one should never use T in an Aldor program
that is to be run inside FriCAS. Bad design, but I don't find that
currently too dramatic as long as it seems to work.
What I still don't understand is... the .lsp file looks (of course)
different if in the .as file I declare
domainConstant: () -> %
instead of
domainConstant: %.
However, in FriCAS, )sh DomainConstant shows me the first form for both
versions of the .as file. Is there some magic in FriCAS that actually
deals with Aldor constants? Or would you simply call it dangerous, if
Aldor constants meet FriCAS?
>> (3) -> domainConstant()$D
>> Internal Error
>> Unexpected error or improper call to system function matchMmCond :
>> unknown form of condition
>>
>
> matchMmCond (in i-funsel.boot) is complaining about malformed
> consition in a modemap.
>
> First thing to check is:
>
> )lisp (showdatabase '|domainConstant|)
This is for "T: BasicType", but it's the same for "X: BasicType".
(1) -> )lisp (showdatabase '|domainConstant|)
CONSTRUCTORKIND: NIL
COSIG: NIL
OPERATION: (((*1 *1)
(AND (isDomain *1 (DomainConstant *2))
(ofCategory *2 (BasicType)))))
CONSTRUCTORMODEMAP:
NIL
CONSTRUCTORCATEGORY:
NIL
OPERATIONALIST:
NIL
MODEMAPS:
NIL
HASCATEGORY: NIL
OBJECT: NIL
NILADIC: NIL
ABBREVIATION: NIL
CONSTRUCTOR?: NIL
CONSTRUCTOR: NIL
DEFAULTDOMAIN: NIL
ANCESTORS: NIL
SOURCEFILE: NIL
CONSTRUCTORFORM: NIL
CONSTRUCTORARGS: NIL
ATTRIBUTES: NIL
PREDICATES:
NIL
DOCUMENTATION: NIL
PARENTS: NIL
Value = NIL
> expecially the modemaps part. If modemaps looks reasonable
> than I would trace matchMmCond to see if it really uses
> modemaps form database (we have one known case where we
> temporarily get some strange modemaps, while modemaps in
> database are OK). If modemaps in database are bad, than
> one should look at generated .asy file and choose next
> steps dependig on result.
The generated .asy file contains ...
(|Declare|
t
|BasicType|
((|symeNameCode| . 200125)
(|symeTypeCode| . 866929616)
so that might be the problematic piece.
> I am affraid that to really distinguish constants from nullary
> functions requires significant changes to the compiler -- current
> modemap machinery has no obvius way to distinguish them.
OK, then I'll wait for Aldor to become free. ;-) and :-(
Ralf
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
