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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gcl-devel
