Hi Ralf, thanks.
Perhaps I should have mentioned the origin: even with quoting and type
hints it's quite error-prone.
I'm wondering if there is a possibility to limit (time) the process?
BTW the function name doesn't matter (foo instead of display etc.)
)abbrev domain IDXOBJ IndexedObject
Hi Qian, thank you! I wasn't aware of "bottom on". Now it's evident what's the
crux of the matter. Although I suspected something like this, I wouldn't expect
the interpreter being so persistent.
Quoting (as Ralf already suggested) helps, nevertheless it might be a pitfall.
Greetings
Kurt
On
Indeed it's a problem with conversion. The following returns quickly
dsp(x, ['a,'b,'c,'d,'5,'5,'t,'s,'r,'s,'s,'s,'s])
The problem seems to be that you have the number 5 in your list.
If you evaluate [a,b,c,d,5,5,t,s,r,s,s,s,s] in a session, you get
(18) -> [a,b,c,d,5,5,t,s,r,s,s,s,s]
(18)
You can see what is happening by
")set message bottom on".
It seems to try various type conversions (involving polynomial types)
and fail eventually.
There are other places where a correct program needs long time to type
check.
In that case, adding additional explicit type hints/conversion
I've been confronted with the following oddness when accidentally a wrong
entry (i.e. 1 instead of a symbol) is used:
(1) -> foo(L:List Symbol):OutputForm == first [outputForm(s)$OutputForm for
s in L]
(2) -> foo [a,b,c,1]
Compiling function foo with type List(Symbol) -> OutputForm
