[Gcl-devel] Re: easiest ANSI upgrade step?

[Camm Maguire]

Greetings, and thanks for your suggestion!  What timing -- I had just
gotten to subtypep.complex.7.  A minor modification to your suggestion
allows us to pass all numeric subtypep tests:

(defun upgraded-complex-part-type (type &optional environment) (declare (ignore 
environment)) type)

subtypep(-float -integer -rational -complex -real).lsp

This is now in in my local copy.  Thanks again!

With the new compiler loop inlining, heavy use has been made of type
propagation allowing the elimination of branches known to be
unreachable in the code.  This basically allows us to expand the loops
into generic all-purpose lisp in via compiler macros and rely on
branch elimination to inline the optimized version when appropriate.
All the list functions are now written this way, and the sequence
functions are coming soon.  The same mechanism coincidentally allowed
automatic pcl instance type detection in the clos.  Still haven't
committed this as I want it to be as solid as possible before I leave
on vacation next week.

The type intersection code has also provided a more robust subtypep
via (type-null `(and ,x (not ,y))) detection.  The tests are much
easier to pass with some inkling of a solid logical structure behind
it.  The performance might need a little work, but this centralization
of the type handling between the 'si and 'compiler packages has been
in great need of addressing for a long time.  It looks as if things
are coming together now, after which static build and plet are next.

compiler notes are in place for auto variable declaration and branch
elimination.  I'd like to define a few more categories one could push
to a list to report only the information one is interested in.

I was at first discouraged that Paul's indication that subtypep could
not use the second return value to indicate disjointedness would
complicate things greatly, but thus far, I'm always able to return T
for the above mentioned tests and still pass!  Hope the other
categories can follow too.

Take care,



Robert Boyer <address@hidden> writes:

> The following might be the easiest instance of making a change to GCL towards
> ANSI compatibility.
> 
> Currently, UPGRADED-COMPLEX-PART-TYPE is one of those functions simply not
> yet in the package COMMON-LISP, and it needs a definition for ANSI
> compliance.
> 
> At http://www.caddr.com/macho/archives/sbcl-devel/2004-5/3400.html, Bruno
> Hailbe (of CLISP) suggests the following definition as (minimally)
> acceptable:
> 
>  (defun upgraded-complex-part-type (type &optional environment)
>    (cond ((subtypep type 'NIL) 'NIL)
>          (t 'REAL)))
> 
> He also offers some more refined and interesting definitions, but whether
> they apply to GCL as opposed to SBCL I have no idea.  Since probably no one I
> have or ever will meet has or ever will call UPGRADED-COMPLEX-PART-TYPE
> except as a joke, it is probably not very necessary to consider refinements;
> but what do I know.  But you might want to add this three line definition to
> GCL and then wait till someone asks for a better one.
> 
> Bob
> 
> 
> 

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