oldk1331 wrote:
>
> > Probably because T has the fixed meaning (True) in lisp.
>
> Hmm, good catch! You are right, if you use "NIL" as a type
> variable, you can't compile it:
>
> >> System error:
> The value
> |t#1|
> is not of type
> SEQUENCE
>
> After some debugging, I find this bug happens at a very early stage:
> parsing. In scwrap2.boot, fakeloopProcess1, the tok_list is fine, but
> parseout is not: NIL got evaluated.
Currently internal representation of types must be a Lisp
S-expression which after a little conversion may be passed to
'eval'. That is why we need to replace 'T' by 'T$'. With
NIL situation is worse, we can not distinguish sumbol NIL from
empty list.
We could try to work around such problems using Lisp package
system, so that T and NIL in COMMON-LISP package have standard
Lisp meaning, but T and NIL in BOOT package are just symbols
with no special meaning. I did some work in this directions,
but this is a lot of work and at least in intermediate stages
would lead to ugly code.
Let me add that there are several other magic symbols: if you
use them they will be treated as internal representation
of various structures and from user point of view behave
in strange way. ATM I decided to live with this: change
would be significant work and would make debugging of
interpreter harder.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
