[Gcl-devel] Re: stuff

[Camm Maguire]

Greetings!  Back from break.

Reviewing this and other code, it appears that my initial hope of
proclaiming virtually every function as return type t or less is not
possible even in theory for many common usage patterns in lisp.
Hence, I think it is a good idea to accelerate the generic call --
this can be done by writing them exactly as a vararg fast-link
function returning multiple values, but with the stack space mv return
area allocated to hold at most multiple-values-limit values.  GCL
currently does not enforce multiple-values-limit, which is set
conservatively at 32.  Spec says anything over 20.  Even though 32 is
small, this seems bound to cover almost all cases -- we could even
automatically cons up larger mv returns into one list return
automatically. 

Testing this here and it looks good so far.  It does obsolete a bunch
of code, and breaks the logical separation of the functions --
everything is a fast link now, t3defun-normal is never called -- but
this might be worth looking into.

Take care,

Robert Boyer <address@hidden> writes:

> > Here is my suggestion
> 
> Thanks very much.  I'll try what you suggest.
> 
> By the way, nqthm build time is now down to 1 minute 40 seconds with the
> nqthm proclaims back in and a very recent 2.7.0.
> 
> > I am not getting the unused variable warnings in nqthm.
> 
> Nor am I.  Thanks so much.
> 
> > the ret mismatch warnings in nqthm
> 
> A very good question, all 88 of them.  Here are a few half-baked answers.
> I have not yet seen GCL strictly 'wrong' once, but ...
> 
> PACK -- gcl is right because 'intern' returns two values, alas, unlike in, 
> say,
>         maybe in 1975.  But nqthm never care about this second value 
>         (status---one of inherited, external, internal, or nil).  So where 
> does that
>         leave us as far as errors and efficiency go?
> *1*PACK -- see PACK
> *1*APPLY$ -- interesting question here -- gcl is right in the sense that
>              funcall 'might' return many values, but not from a call of 
>              *1*apply in nqthm in 'normal' usage (well, except for maybe
>              *1*pack and ??)
> *1**EVAL$ -- ..
> ADD-EQUATIONS -- well, 'catch' can return multiple values, but not in nqthm 
> (cause they
>                  didn't have multiple values in the dark ages) except ... 
> maybe
>                  *1*pack and pack and ??
> ADD-EQUATIONS-TO-POT-LST -- ..
> EXECUTE -- see *1*apply$
> FERTILIZE-SENT -- ..
> GENERALIZE-SENT -- ..
> SIMPLIFY-SENT -- ..
> ELIMINATE-DESTRUCTORS-SENT -- ..
> ELIMINATE-IRRELEVANCE-SENT -- ..
> GET-STACK-NAME -- cf. PACK
> IF-NOT-NQTHM-MODE -- cf. *1*apply
> IF-NQTHM-MODE -- ..
> REDUCE-TERM -- cf. catch
> REDUCE-TERM1 -- cf. apply
> REWRITE-FNCALL -- cf. catch
> SETTLED-DOWN-SENT -- cf. execute
> SIMPLIFY-LOOP -- cf. catch
> STORE-DEFINITION -- gcl is right, 'compile' really does return 3 now
> TIME-IN-60THS -- gcl is right, 'floor' can return 2
> VVV- -- PACK again!
> PEVAL-APPLY -- cf. *1*apply
> TH-IFY -- cf. PACK
> PUTD1 -- compile!
> PEVAL -- cf. apply
> 
> I'm too tired to get up to 88 tonight.  Let me know if you'd like me to
> finish all 88.
> 
> Thanks so very much!
> 
> Bob
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah