| blob | 75c81eab4868abc519bf7146e68080befb34c646 |
1 ;;;; This file contains code which does the translation of lambda
2 ;;;; forms from Lisp code to the first intermediate representation
3 ;;;; (IR1).
5 ;;;; This software is part of the SBCL system. See the README file for
6 ;;;; more information.
7 ;;;;
8 ;;;; This software is derived from the CMU CL system, which was
9 ;;;; written at Carnegie Mellon University and released into the
10 ;;;; public domain. The software is in the public domain and is
11 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
12 ;;;; files for more information.
16 ;;;; LAMBDA hackery
18 ;;;; Note: Take a look at the compiler-overview.tex section on "Hairy
19 ;;;; function representation" before you seriously mess with this
20 ;;;; stuff.
22 ;;; Verify that the NAME is a legal name for a variable and return a
23 ;;; VAR structure for it, filling in info if it is globally special.
24 ;;; If it is losing, we punt with a COMPILER-ERROR. NAMES-SO-FAR is a
25 ;;; list of names which have previously been bound. If the NAME is in
26 ;;; this list, then we error out.
34 name))
38 name))
48 ;;; Make the default keyword for a &KEY arg, checking that the keyword
49 ;;; isn't already used by one of the VARS.
54 symbol)))
61 "The keyword ~S appears more than once in the lambda list."
62 key))))
63 key))
65 ;;; Parse a lambda list into a list of VAR structures, stripping off
66 ;;; any &AUX bindings. Each arg name is checked for legality, and
67 ;;; duplicate names are checked for. If an arg is globally special,
68 ;;; the var is marked as :SPECIAL instead of :LEXICAL. &KEY,
69 ;;; &OPTIONAL and &REST args are annotated with an ARG-INFO structure
70 ;;; which contains the extra information. If we hit something losing,
71 ;;; we bug out with COMPILER-ERROR. These values are returned:
72 ;;; 1. a list of the var structures for each top level argument;
73 ;;; 2. a flag indicating whether &KEY was specified;
74 ;;; 3. a flag indicating whether other &KEY args are allowed;
75 ;;; 4. a list of the &AUX variables; and
76 ;;; 5. a list of the &AUX values.
78 make-lambda-vars))
81 morep more-context more-count)
89 ;; for optionals and keywords args.
101 "The list ~S is too long to be an arg specifier."
102 spec)))))))
150 t)))
173 nil))))
188 spec))
197 ;;; This is similar to IR1-CONVERT-PROGN-BODY except that we
198 ;;; sequentially bind each AUX-VAR to the corresponding AUX-VAL before
199 ;;; converting the body. If there are no bindings, just convert the
200 ;;; body, otherwise do one binding and recurse on the rest.
201 ;;;
202 ;;; FIXME: This could and probably should be converted to use
203 ;;; SOURCE-NAME and DEBUG-NAME. But I (WHN) don't use &AUX bindings,
204 ;;; so I'm not motivated. Patches will be accepted...
217 "&AUX bindings "
218 aux-vars))))
224 ;;; This is similar to IR1-CONVERT-PROGN-BODY except that code to bind
225 ;;; the SPECVAR for each SVAR to the value of the variable is wrapped
226 ;;; around the body. If there are no special bindings, we just convert
227 ;;; the body, otherwise we do one special binding and recurse on the
228 ;;; rest.
229 ;;;
230 ;;; We make a cleanup and introduce it into the lexical
231 ;;; environment. If there are multiple special bindings, the cleanup
232 ;;; for the blocks will end up being the innermost one. We force NEXT
233 ;;; to start a block outside of this cleanup, causing cleanup code to
234 ;;; be emitted when the scope is exited.
254 body aux-vars aux-vals
258 ;;; Create a lambda node out of some code, returning the result. The
259 ;;; bindings are specified by the list of VAR structures VARS. We deal
260 ;;; with adding the names to the LEXENV-VARS for the conversion. The
261 ;;; result is added to the NEW-FUNCTIONALS in the *CURRENT-COMPONENT*
262 ;;; and linked to the component head and tail.
263 ;;;
264 ;;; We detect special bindings here, replacing the original VAR in the
265 ;;; lambda list with a temporary variable. We then pass a list of the
266 ;;; special vars to IR1-CONVERT-SPECIAL-BINDINGS, which actually emits
267 ;;; the special binding code.
268 ;;;
269 ;;; We ignore any ARG-INFO in the VARS, trusting that someone else is
270 ;;; dealing with &NONSENSE, except for &REST vars with DYNAMIC-EXTENT.
271 ;;;
272 ;;; AUX-VARS is a list of VAR structures for variables that are to be
273 ;;; sequentially bound. Each AUX-VAL is a form that is to be evaluated
274 ;;; to get the initial value for the corresponding AUX-VAR.
276 vars
277 &key
278 aux-vars
279 aux-vals
281 debug-name
285 ;; We're about to try to put new blocks into *CURRENT-COMPONENT*.
290 :bind bind
291 :%source-name source-name
300 ;; just to check: This function should fail internal assertions if
301 ;; we didn't set up a valid debug name above.
302 ;;
303 ;; (In SBCL we try to make everything have a debug name, since we
304 ;; lack the omniscient perspective the original implementors used
305 ;; to decide which things didn't need one.)
313 ;; As far as I can see, LAMBDA-VAR-HOME should never have
314 ;; been set before. Let's make sure. -- WHN 2001-09-29
327 :lambda lambda
350 result-lvar body
356 lambda))
358 ;;; Entry point CLAMBDAs have a special kind
365 entry)
367 ;;; Create the actual entry-point function for an optional entry
368 ;;; point. The lambda binds copies of each of the VARS, then calls FUN
369 ;;; with the argument VALS and the DEFAULTS. Presumably the VALS refer
370 ;;; to the VARS by name. The VALS are passed in the reverse order.
371 ;;;
372 ;;; If any of the copies of the vars are referenced more than once,
373 ;;; then we mark the corresponding var as EVER-USED to inhibit
374 ;;; "defined but not read" warnings for arguments that are only used
375 ;;; by default forms.
385 fvars))
398 arg-vars
399 :debug-name
406 fvars arg-vars)
407 fun))
409 ;;; This function deals with supplied-p vars in optional arguments. If
410 ;;; the there is no supplied-p arg, then we just call
411 ;;; IR1-CONVERT-HAIRY-ARGS on the remaining arguments, and generate a
412 ;;; optional entry that calls the result. If there is a supplied-p
413 ;;; var, then we add it into the default vars and throw a T into the
414 ;;; entry values. The resulting entry point function is returned.
416 entry-vars entry-vals
417 vars supplied-p-p body
418 aux-vars aux-vals
419 source-name debug-name
420 force)
423 aux-vars aux-vals))
433 res
439 source-name debug-name
440 force)
442 res
448 source-name debug-name
449 force))))
451 ;; We want to delay converting the entry, but there exist
452 ;; problems: hidden references should not be established to
453 ;; lambdas of kind NIL should not have (otherwise the compiler
454 ;; might let-convert or delete them) and to variables.
456 supplied-p-p ; this entry will be of kind NIL
459 default-vars default-vals
466 default-vars default-vals
470 res)))))
472 ;;; Create the MORE-ENTRY function for the OPTIONAL-DISPATCH RES.
473 ;;; ENTRY-VARS and ENTRY-VALS describe the fixed arguments. REST is
474 ;;; the var for any &REST arg. KEYS is a list of the &KEY arg vars.
475 ;;;
476 ;;; The most interesting thing that we do is parse keywords. We create
477 ;;; a bunch of temporary variables to hold the result of the parse,
478 ;;; and then loop over the supplied arguments, setting the appropriate
479 ;;; temps for the supplied keyword. Note that it is significant that
480 ;;; we iterate over the keywords in reverse order --- this implements
481 ;;; the CL requirement that (when a keyword appears more than once)
482 ;;; the first value is used.
483 ;;;
484 ;;; If there is no supplied-p var, then we initialize the temp to the
485 ;;; default and just pass the temp into the main entry. Since
486 ;;; non-constant &KEY args are forcibly given a supplied-p var, we
487 ;;; know that the default is constant, and thus safe to evaluate out
488 ;;; of order.
489 ;;;
490 ;;; If there is a supplied-p var, then we create temps for both the
491 ;;; value and the supplied-p, and pass them into the main entry,
492 ;;; letting it worry about defaulting.
493 ;;;
494 ;;; We deal with :ALLOW-OTHER-KEYS by delaying unknown keyword errors
495 ;;; until we have scanned all the keywords.
603 ;;; This is called by IR1-CONVERT-HAIRY-ARGS when we run into a &REST
604 ;;; or &KEY arg. The arguments are similar to that function, but we
605 ;;; split off any &REST arg and pass it in separately. REST is the
606 ;;; &REST arg var, or NIL if there is no &REST arg. KEYS is a list of
607 ;;; the &KEY argument vars.
608 ;;;
609 ;;; When there are &KEY arguments, we introduce temporary gensym
610 ;;; variables to hold the values while keyword defaulting is in
611 ;;; progress to get the required sequential binding semantics.
612 ;;;
613 ;;; This gets interesting mainly when there are &KEY arguments with
614 ;;; supplied-p vars or non-constant defaults. In either case, pass in
615 ;;; a supplied-p var. If the default is non-constant, we introduce an
616 ;;; IF in the main entry that tests the supplied-p var and decides
617 ;;; whether to evaluate the default or not. In this case, the real
618 ;;; incoming value is NIL, so we must union NULL with the declared
619 ;;; type when computing the type for the main entry's argument.
621 rest more-context more-count keys supplied-p-p
622 body aux-vars aux-vals
623 source-name debug-name)
626 aux-vars aux-vals))
646 "~A-DEFAULTING-TEMP"
650 :%source-name n-val
653 key-type))))
693 last-entry)
694 res)
696 last-entry)))
698 ;;; This function generates the entry point functions for the
699 ;;; OPTIONAL-DISPATCH RES. We accomplish this by recursion on the list
700 ;;; of arguments, analyzing the arglist on the way down and generating
701 ;;; entry points on the way up.
702 ;;;
703 ;;; DEFAULT-VARS is a reversed list of all the argument vars processed
704 ;;; so far, including supplied-p vars. DEFAULT-VALS is a list of the
705 ;;; names of the DEFAULT-VARS.
706 ;;;
707 ;;; ENTRY-VARS is a reversed list of processed argument vars,
708 ;;; excluding supplied-p vars. ENTRY-VALS is a list things that can be
709 ;;; evaluated to get the values for all the vars from the ENTRY-VARS.
710 ;;; It has the var name for each required or optional arg, and has T
711 ;;; for each supplied-p arg.
712 ;;;
713 ;;; VARS is a list of the LAMBDA-VAR structures for arguments that
714 ;;; haven't been processed yet. SUPPLIED-P-P is true if a supplied-p
715 ;;; argument has already been processed; only in this case are the
716 ;;; DEFAULT-XXX and ENTRY-XXX different.
717 ;;;
718 ;;; The result at each point is a lambda which should be called by the
719 ;;; above level to default the remaining arguments and evaluate the
720 ;;; body. We cause the body to be evaluated by converting it and
721 ;;; returning it as the result when the recursion bottoms out.
722 ;;;
723 ;;; Each level in the recursion also adds its entry point function to
724 ;;; the result OPTIONAL-DISPATCH. For most arguments, the defaulting
725 ;;; function and the entry point function will be the same, but when
726 ;;; SUPPLIED-P args are present they may be different.
727 ;;;
728 ;;; When we run into a &REST or &KEY arg, we punt out to
729 ;;; IR1-CONVERT-MORE, which finishes for us in this case.
731 entry-vars entry-vals
732 vars supplied-p-p body aux-vars
733 aux-vals
734 source-name debug-name
735 force)
738 aux-vars aux-vals))
741 ;; Handle &KEY with no keys...
743 entry-vars entry-vals
744 nil nil nil vars supplied-p-p body aux-vars
745 aux-vals source-name debug-name)
748 :aux-vars aux-vars
749 :aux-vals aux-vals
751 "hairy arg processor for "
752 source-name
753 debug-name))))
759 res)
760 fun)
762 fun)))
769 source-name debug-name
770 nil)))
776 (:optional
778 res default-vars default-vals
779 entry-vars entry-vals vars supplied-p-p body
780 aux-vars aux-vals
781 source-name debug-name
782 force)))
783 ;; See GENERATE-OPTIONAL-DEFAULT-ENTRY.
788 ep)
789 res)
791 ep))
793 ep))
794 (:rest
796 entry-vars entry-vals
798 aux-vars aux-vals
799 source-name debug-name))
800 (:more-context
802 entry-vars entry-vals
804 body aux-vars aux-vals
805 source-name debug-name))
806 (:keyword
808 entry-vars entry-vals
809 nil nil nil vars supplied-p-p body aux-vars
810 aux-vals source-name debug-name)))))))
812 ;;; This function deals with the case where we have to make an
813 ;;; OPTIONAL-DISPATCH to represent a LAMBDA. We cons up the result and
814 ;;; call IR1-CONVERT-HAIRY-ARGS to do the work. When it is done, we
815 ;;; figure out the MIN-ARGS and MAX-ARGS.
817 &key
820 "OPTIONAL-DISPATCH "
821 vars)))
824 :allowp allowp
825 :keyp keyp
826 :%source-name source-name
827 :%debug-name debug-name
835 source-name debug-name nil)
840 res))
842 ;;; Convert a LAMBDA form into a LAMBDA leaf or an OPTIONAL-DISPATCH leaf.
844 debug-name)
849 form))
852 'lambda
854 form))
857 "The lambda expression has a missing or non-list lambda list:~% ~S"
858 form))
870 forms))
872 forms
876 allow-other-keys
877 aux-vars aux-vals
878 :source-name source-name
881 :aux-vars aux-vars
882 :aux-vals aux-vals
883 :source-name source-name
887 res))))
889 ;;; helper for LAMBDA-like things, to massage them into a form
890 ;;; suitable for IR1-CONVERT-LAMBDA.
891 ;;;
892 ;;; KLUDGE: We cons up a &REST list here, maybe for no particularly
893 ;;; good reason. It's probably lost in the noise of all the other
894 ;;; consing, but it's still inelegant. And we force our called
895 ;;; functions to do full runtime keyword parsing, ugh. -- CSR,
896 ;;; 2003-01-25
899 debug-name)
907 res))
913 :source-name name
914 :debug-name nil
915 args)))
918 res)
923 res defined-fun-res))
924 res)
928 \f
929 ;;;; defining global functions
931 ;;; Convert FUN as a lambda in the null environment, but use the
932 ;;; current compilation policy. Note that FUN may be a
933 ;;; LAMBDA-WITH-LEXENV, so we may have to augment the environment to
934 ;;; reflect the state at the definition site.
937 debug-name)
949 macros)
952 :source-name source-name
955 ;;; Get a DEFINED-FUN object for a function we are about to define. If
956 ;;; the function has been forward referenced, then substitute for the
957 ;;; previous references.
966 :%source-name name
972 ;; If *FREE-FUNS* has a previously converted definition
973 ;; for this name, then blow it away and try again.
979 ;;; Check a new global function definition for consistency with
980 ;;; previous declaration or definition, and assert argument/result
981 ;;; types if appropriate. This assertion is suppressed by the
982 ;;; EXPLICIT-CHECK attribute, which is specified on functions that
983 ;;; check their argument types as a consequence of type dispatching.
984 ;;; This avoids redundant checks such as NUMBERP on the args to +, etc.
990 fun type
991 ;; KLUDGE: Common Lisp is such a dynamic language that in general
992 ;; all we can do here in general is issue a STYLE-WARNING. It
993 ;; would be nice to issue a full WARNING in the special case of
994 ;; of type mismatches within a compilation unit (as in section
995 ;; 3.2.2.3 of the spec) but at least as of sbcl-0.6.11, we don't
996 ;; keep track of whether the mismatched data came from the same
997 ;; compilation unit, so we can't do that. -- WHN 2001-02-11
1002 :really-assert
1006 explicit-check))))
1008 "previous declaration"
1011 ;;; Convert a lambda doing all the basic stuff we would do if we were
1012 ;;; converting a DEFUN. In the old CMU CL system, this was used both
1013 ;;; by the %DEFUN translator and for global inline expansion, but
1014 ;;; since sbcl-0.pre7.something %DEFUN does things differently.
1015 ;;; FIXME: And now it's probably worth rethinking whether this
1016 ;;; function is a good idea.
1017 ;;;
1018 ;;; Unless a :INLINE function, we temporarily clobber the inline
1019 ;;; expansion. This prevents recursive inline expansion of
1020 ;;; opportunistic pseudo-inlines.
1033 ;; If definitely not an interpreter stub, then substitute for
1034 ;; any old references.
1042 ;; If in a simple environment, then we can allow backward
1043 ;; references to this function from following top level forms.
1045 fun)))
1047 ;;; the even-at-compile-time part of DEFUN
1048 ;;;
1049 ;;; The INLINE-EXPANSION is a LAMBDA-WITH-LEXENV, or NIL if there is
1050 ;;; no inline expansion.
1056 ;; better be in the compiler
1072 lambda-with-lexenv)
1075 lambda-with-lexenv)))
1079 ;; old CMU CL comment:
1080 ;; If there is a type from a previous definition, blast it,
1081 ;; since it is obsolete.
1085 ;; FIXME: If this is a block compilation thing, shouldn't
1086 ;; we be setting the type to the full derived type for the
1087 ;; definition, instead of this most general function type?
1092 \f
1093 ;;; Entry point utilities
1095 ;;; Return a function for the Nth entry point.