<commit_before>
Syntax Utilities
----------------

The libraries of the "syntax" collection provide utilities for
manipulating expressions and inspecting modules.

======================================================================
_stx.ss_: deconstructing syntax objects
======================================================================

> (stx-null? v) - returns #t if `v' is either the empty list or a
  syntax object representing the empty list (i.e., `syntax-e' on the
  syntax object returns the empty list).

> (stx-pair? v) - returns #t if `v' is either a pair or a syntax
  object representing a pair. See also the definition of "syntax pair"
  in the MzScheme manual.

> (stx-list? v) - returns #t if `v' is a list, or if it is a sequence
  of pairs leading to a syntax object such that `syntax->list' (from
  MzScheme) would produce a list.

> (stx->list stx-list) - produces a list by flatting out a trailing
  syntax object using `syntax->list'. The `stx-list' argument must be
  a value for which `stx-list?' would return #t.

> (stx-car v) - takes the car of a "syntax pair". See the definition
  of "syntax pair" in the MzScheme manual.

> (stx-cdr v) - takes the cdr of a "syntax pair". See the definition
  of "syntax pair" in the MzScheme manual.

> (module-or-top-identifier=? a-id b-id) - returns #t if `a-id' and
  `b-id' are module-identifier=?, or if `a-id' and `b-id' have the
  same name (as extracted by `syntax-e') and `a-id' has no binding
  other than at the top level.

  This procedure is useful in conjunction with `syntax-case*' to match
  procedure names that are normally bound by MzScheme. For example,
  the `include' macro uses this procedure to recognize `build-path';
  using `module-identifier=?'  would not work well outside of
  `module', since the top-level `build-path' is a distinct variable
  from the MzScheme export (though it's bound to the same procedure,
  initially).

======================================================================
_kerncase.ss_: matching fully-expanded expressions
======================================================================

> (kernel-syntax-case stx-expr trans?-expr clause ...) - a syntactic
  form like `syntax-case*', except that the literals are built-in as
  the names of the primitive MzScheme forms. (The primitive syntactic
  forms must have their normal bindings in the context of the
  `kernel-syntax-case' expression.)

  The `trans?-expr' boolean expression replaces the comparison
  procedure, and instead selects simply between normal-phase
  comparisons or transformer-phase comparisons. The `clause's are
  the same as in `syntax-case*'.

> (kernel-syntax-case* stx-expr trans?-expr (extras ...) clause ...) -
  a syntactic form like `kernel-syntax-case', except that it takes an
  additional list of extra literals that are used as well as the
  primitive MzScheme forms.

> (kernel-form-identifier-list syntax) - returns a list of identifiers
  for the names of the primitive MzScheme forms for expressions, with
  the lexical context of `syntax'. This function is useful for
  generating a list of stopping points to provide to `local-expand'.

======================================================================
_toplevel.ss_: helper for moduleless compilation and expansion
======================================================================

> (expand-top-level-with-compile-time-evals stx) - expands `stx' as
  a top-level expression, and evaluates its compile-time portion for
  the benefit of later expansions.

  The expander recognizes top-level `begin' expressions, and
  interleaves the evaluation and expansion of of the `begin' body, so
  that compile-time expressions within the `begin' body affect later
  expansions within the body. (In other words, it ensures that
  expanding a `begin' is the same as expanding separate top-level
  expressions.)

  The `stx' argument should have a context already, possibly
  introduced with `namespacae-introduce-syntax'.

> (expand-top-level-with-compile-time-evals/flatten stx) - 
  Just like expand-top-level-with-compile-time-evals,
  except that it returns a list of syntax objects, none of
  which have a begin. These syntax objects are the
  flattened out contents of any begins in `stx'.

> (expand-syntax-top-level-with-compile-time-evals stx)
  Like `expand-top-level-with-compile-time-evals', but `stx' should
  have a context already, possibly introduced with
  `namespacae-introduce-syntax'.

> (eval-compile-time-part-of-top-level stx) - evaluates
  expansion-time code in the fully expanded top-level expression
  represented by `stx (or a part of it, in the case of `begin'
  expressions). The expansion-time code might affect the compilation
  of later top-level expressions. For example, if `stx is a
  `require' expression, then `namespace-require/expansion-time' is
  used on each require specification in the form. Normally, this
  function is used only by `expand-top-level-with-compile-time-evals'.

> (eval-compile-time-part-of-top-level/compile stx) - like
  `eval-compile-time-part-of-top-level', but the result is compiled
  code.

======================================================================
_define.ss_: handling all the same function forms as `define'
======================================================================<commit_msg>doc corrections for expand-syntax-top-level-with-compile-time-evals et al.<commit_after>
Syntax Utilities
----------------

The libraries of the "syntax" collection provide utilities for
manipulating expressions and inspecting modules.

======================================================================
_stx.ss_: deconstructing syntax objects
======================================================================

> (stx-null? v) - returns #t if `v' is either the empty list or a
  syntax object representing the empty list (i.e., `syntax-e' on the
  syntax object returns the empty list).

> (stx-pair? v) - returns #t if `v' is either a pair or a syntax
  object representing a pair. See also the definition of "syntax pair"
  in the MzScheme manual.

> (stx-list? v) - returns #t if `v' is a list, or if it is a sequence
  of pairs leading to a syntax object such that `syntax->list' (from
  MzScheme) would produce a list.

> (stx->list stx-list) - produces a list by flatting out a trailing
  syntax object using `syntax->list'. The `stx-list' argument must be
  a value for which `stx-list?' would return #t.

> (stx-car v) - takes the car of a "syntax pair". See the definition
  of "syntax pair" in the MzScheme manual.

> (stx-cdr v) - takes the cdr of a "syntax pair". See the definition
  of "syntax pair" in the MzScheme manual.

> (module-or-top-identifier=? a-id b-id) - returns #t if `a-id' and
  `b-id' are module-identifier=?, or if `a-id' and `b-id' have the
  same name (as extracted by `syntax-e') and `a-id' has no binding
  other than at the top level.

  This procedure is useful in conjunction with `syntax-case*' to match
  procedure names that are normally bound by MzScheme. For example,
  the `include' macro uses this procedure to recognize `build-path';
  using `module-identifier=?'  would not work well outside of
  `module', since the top-level `build-path' is a distinct variable
  from the MzScheme export (though it's bound to the same procedure,
  initially).

======================================================================
_kerncase.ss_: matching fully-expanded expressions
======================================================================

> (kernel-syntax-case stx-expr trans?-expr clause ...) - a syntactic
  form like `syntax-case*', except that the literals are built-in as
  the names of the primitive MzScheme forms. (The primitive syntactic
  forms must have their normal bindings in the context of the
  `kernel-syntax-case' expression.)

  The `trans?-expr' boolean expression replaces the comparison
  procedure, and instead selects simply between normal-phase
  comparisons or transformer-phase comparisons. The `clause's are
  the same as in `syntax-case*'.

> (kernel-syntax-case* stx-expr trans?-expr (extras ...) clause ...) -
  a syntactic form like `kernel-syntax-case', except that it takes an
  additional list of extra literals that are used as well as the
  primitive MzScheme forms.

> (kernel-form-identifier-list syntax) - returns a list of identifiers
  for the names of the primitive MzScheme forms for expressions, with
  the lexical context of `syntax'. This function is useful for
  generating a list of stopping points to provide to `local-expand'.

======================================================================
_toplevel.ss_: helper for moduleless compilation and expansion
======================================================================

> (expand-syntax-top-level-with-compile-time-evals stx) - expands `stx' as
  a top-level expression, and evaluates its compile-time portion for
  the benefit of later expansions.

  The expander recognizes top-level `begin' expressions, and
  interleaves the evaluation and expansion of of the `begin' body, so
  that compile-time expressions within the `begin' body affect later
  expansions within the body. (In other words, it ensures that
  expanding a `begin' is the same as expanding separate top-level
  expressions.)

  The `stx' should have a context already, possibly introduced with
  `namespacae-introduce-syntax'.

  The `stx' argument need not have a context already; a context is
  supplied with `namespace-introduce-syntax'.

> (expand-top-level-with-compile-time-evals stx) - like
  `expand-syntax-top-level-with-compile-time-evals', but `stx' is
  first given context by applying `namespace-introduce-syntax' to it.

> (expand-top-level-with-compile-time-evals/flatten stx) - like
  `expand-syntax-top-level-with-compile-time-evals', except that it
  returns a list of syntax objects, none of which have a
  `begin'. These syntax objects are the flattened out contents of any
  `begin's in the expansion of `stx'.

> (eval-compile-time-part-of-top-level stx) - evaluates
  expansion-time code in the fully expanded top-level expression
  represented by `stx' (or a part of it, in the case of `begin'
  expressions). The expansion-time code might affect the compilation
  of later top-level expressions. For example, if `stx' is a
  `require' expression, then `namespace-require/expansion-time' is
  used on each require specification in the form. Normally, this
  function is used only by `expand-top-level-with-compile-time-evals'.

> (eval-compile-time-part-of-top-level/compile stx) - like
  `eval-compile-time-part-of-top-level', but the result is compiled
  code.

======================================================================
_define.ss_: handling all the same function forms as `define'
======================================================================
{'fraction_non_alphanumeric': 0.18352163130338936, 'fraction_numerical': 0.0, 'mean_word_length': 4.29314535731648, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 39, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3064202', 'n_tokens_mistral': 3044, 'n_tokens_neox': 2882, 'n_words': 1261}