Policy for obsolete funcitons

Policy for obsolete funcitons

[Andrea Corallo]

Hi all,

doing some maintanance in the native compiler I'd like to rename some
function and possibly remove some other.

What's the policy for renaming o removing functions which never meant to
be used as public interfaces (assuming this last bit makes any
difference)?

Can we just do it or we need to obsolete the one we want to remove and
alias the ones that gets renamed?  In case how long is the obsolete
period before we can clean them-up?

Thanks

  Andrea

Re: Policy for obsolete funcitons

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Date: Thu, 02 Nov 2023 13:18:56 -0400
> 
> doing some maintanance in the native compiler I'd like to rename some
> function and possibly remove some other.
> 
> What's the policy for renaming o removing functions which never meant to
> be used as public interfaces (assuming this last bit makes any
> difference)?
> 
> Can we just do it or we need to obsolete the one we want to remove and
> alias the ones that gets renamed?

If the function had a "--" in its name, it is an internal one and can
be renamed.  Otherwise, we need to add an obsolete alias with the old
name.

> In case how long is the obsolete period before we can clean them-up?

Several major releases.

Re: Policy for obsolete funcitons

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <acorallo@gnu.org>
>> Date: Thu, 02 Nov 2023 13:18:56 -0400
>> 
>> doing some maintanance in the native compiler I'd like to rename some
>> function and possibly remove some other.
>> 
>> What's the policy for renaming o removing functions which never meant to
>> be used as public interfaces (assuming this last bit makes any
>> difference)?
>> 
>> Can we just do it or we need to obsolete the one we want to remove and
>> alias the ones that gets renamed?
>
> If the function had a "--" in its name, it is an internal one and can
> be renamed.  Otherwise, we need to add an obsolete alias with the old
> name.

Can't we use the argument that the entry points for the native compiler
are designed to be only the one we named native-*?

Thanks

  Andrea

Re: Policy for obsolete funcitons

[Stefan Kangas]

Andrea Corallo <acorallo@gnu.org> writes:

> Can't we use the argument that the entry points for the native compiler
> are designed to be only the one we named native-*?

The only reference to "^comp-" I find in the elisp manual index is
"comp-native-version-dir".  There's nothing in the emacs manual.

So I think the argument makes sense.

Re: Policy for obsolete funcitons

[Andrea Corallo]

Stefan Kangas <stefankangas@gmail.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> Can't we use the argument that the entry points for the native compiler
>> are designed to be only the one we named native-*?
>
> The only reference to "^comp-" I find in the elisp manual index is
> "comp-native-version-dir".

Hi Stefan,

good finding, that sounds like a good for renaming as well then :D

  Andrea

Re: Policy for obsolete funcitons

[Andrea Corallo]

Andrea Corallo <acorallo@gnu.org> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Andrea Corallo <acorallo@gnu.org> writes:
>>
>>> Can't we use the argument that the entry points for the native compiler
>>> are designed to be only the one we named native-*?
>>
>> The only reference to "^comp-" I find in the elisp manual index is
>> "comp-native-version-dir".
>
> Hi Stefan,
>
> good finding, that sounds like a good for renaming as well then :D
                                     ^^^
                                     good candidate

Re: Policy for obsolete funcitons

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 02 Nov 2023 14:51:33 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If the function had a "--" in its name, it is an internal one and can
> > be renamed.  Otherwise, we need to add an obsolete alias with the old
> > name.
> 
> Can't we use the argument that the entry points for the native compiler
> are designed to be only the one we named native-*?

It's hard to tell something this general.  I suggest to discuss
specific functions you want to rename, if you have a list of them
already.

Re: Policy for obsolete funcitons

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <acorallo@gnu.org>
>> Cc: emacs-devel@gnu.org
>> Date: Thu, 02 Nov 2023 14:51:33 -0400
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > If the function had a "--" in its name, it is an internal one and can
>> > be renamed.  Otherwise, we need to add an obsolete alias with the old
>> > name.
>>
>> Can't we use the argument that the entry points for the native compiler
>> are designed to be only the one we named native-*?
>
> It's hard to tell something this general.  I suggest to discuss
> specific functions you want to rename, if you have a list of them
> already.

Yes in comp-cstr.el the ones named without the doulbe dash and not
mentioned enywhere outside comp-cstr.el itself.  To a quick scan using
some scripting:

comp-cstr-intersection-make, comp-cstr-union-make, comp-cstr-symbol-p,
comp-cstr-union-1, comp-cstr-union-homogeneous,
comp-cstr-union-homogeneous-no-range, comp-cstr-sub-2, comp-cstr-add-2
comp-range-negation, comp-range-intersection, comp-range-union,
comp-intersect-typesets, comp-intersect-two-typesets,
comp-union-typesets comp-supertypes, comp-normalize-typeset,
comp-intersection-valsets comp-union-valsets, comp-normalize-valset,
comp-split-pos-neg comp-cstrs-homogeneous, comp-cstr-copy.

And similarly in comp.el:

comp-known-predicate-p, comp-pred-to-cstr,
comp-block-preds, comp-gen-counter,
comp-ensure-native-compiler,
comp-equality-fun-p, comp-arithm-cmp-fun-p, comp-set-op-p,
comp-assign-op-p, comp-call-op-p, comp-branch-op-p,
comp-type-hint-p, comp-func-unique-in-cu-p, comp-function-pure-p,
comp-alloc-class-to-container, comp-prettyformat-mvar,
comp-prettyformat-insn, comp-log-func, comp-log-edges,
comp-lex-byte-func-p, comp-spill-decl-spec, comp-spill-speed,
comp-decrypt-arg-list, comp-add-func-to-ctxt,
comp-intern-func-in-ctxt, comp-spill-lap, comp-lap-eob-p,
comp-lap-fall-through-p, comp-bb-maybe-add, comp-callref,
comp-new-frame, comp-emit, comp-emit-set-call, comp-copy-slot,
comp-make-curr-block, comp-latch-make-fill, comp-emit-uncond-jump,
comp-emit-cond-jump, comp-emit-handler, comp-limplify-listn,
comp-new-block-sym, comp-fill-label-h,
comp-jump-table-optimizable, comp-emit-switch,
comp-emit-set-call-subr, comp-op-to-fun, comp-body-eff,
comp-limplify-lap-inst, comp-emit-narg-prologue,
comp-limplify-finalize-function, comp-emit-lambda-for-top-level,
comp-limplify-top-level, comp-addr-to-bb-name,
comp-limplify-block, comp-limplify-function, comp-limplify,
comp-collect-mvars, comp-collect-rhs, comp-negate-arithm-cmp-fun,
comp-reverse-arithm-fun, comp-emit-assume, comp-maybe-add-vmvar,
comp-add-new-block-between, comp-cond-cstrs-target-mvar,
comp-add-cond-cstrs-target-block, comp-add-cond-cstrs-simple,
comp-add-cond-cstrs, comp-emit-call-cstr, comp-lambda-list-gen,
comp-add-call-cstr, comp-add-cstrs, comp-collect-calls,
comp-pure-infer-func, comp-ipa-pure, comp-clean-ssa,
comp-compute-edges, comp-collect-rev-post-order,
comp-compute-dominator-tree, comp-compute-dominator-frontiers,
comp-log-block-info, comp-place-phis, comp-dom-tree-walker,
comp-ssa-rename-insn, comp-ssa-rename, comp-finalize-phis,
comp-remove-unreachable-blocks, comp-ssa, comp-copy-insn,
comp-fwprop-prologue, comp-function-foldable-p,
comp-function-call-maybe-fold, comp-fwprop-call, comp-fwprop-insn,
comp-fwprop*, comp-rewrite-non-locals, comp-fwprop,
comp-func-in-unit, comp-call-optim-form-call,
comp-call-optim-func, comp-call-optim, comp-collect-mvar-ids,
comp-dead-assignments-func, comp-dead-code,
comp-form-tco-call-seq, comp-tco-func, comp-tco,
comp-remove-type-hints-func, comp-remove-type-hints,
comp-args-to-lambda-list, comp-compute-function-type,
comp-finalize-container, comp-finalize-relocs,
comp-compile-ctxt-to-file, comp-final1, comp-final,
comp-eln-load-path-eff,
comp-trampoline-filename, comp-make-lambda-list-from-subr,
comp-trampoline-search, comp-trampoline-compile,
comp-async-runnings, comp-effective-async-max-jobs,
comp-accept-and-process-async-output, comp-run-async-workers.

I think they are all very internal to the compiler machinery, they
tipically manipulate compiler specific kind of objects often requiring a
very specific contex setup in order not to error.

I can't see a use for them as generic library.  I think they should move
to the -- convention.

Thanks

  Andrea

Re: Policy for obsolete funcitons

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 03 Nov 2023 06:33:29 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It's hard to tell something this general.  I suggest to discuss
> > specific functions you want to rename, if you have a list of them
> > already.
> 
> Yes in comp-cstr.el the ones named without the doulbe dash and not
> mentioned enywhere outside comp-cstr.el itself.  To a quick scan using
> some scripting:
> 
> comp-cstr-intersection-make, comp-cstr-union-make, comp-cstr-symbol-p,
> comp-cstr-union-1, comp-cstr-union-homogeneous,
> comp-cstr-union-homogeneous-no-range, comp-cstr-sub-2, comp-cstr-add-2
> comp-range-negation, comp-range-intersection, comp-range-union,
> comp-intersect-typesets, comp-intersect-two-typesets,
> comp-union-typesets comp-supertypes, comp-normalize-typeset,
> comp-intersection-valsets comp-union-valsets, comp-normalize-valset,
> comp-split-pos-neg comp-cstrs-homogeneous, comp-cstr-copy.
> 
> And similarly in comp.el:

Which one(s) would you want to rename, to what names, and why?

Re: Policy for obsolete funcitons

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <acorallo@gnu.org>
>> Cc: emacs-devel@gnu.org
>> Date: Fri, 03 Nov 2023 06:33:29 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > It's hard to tell something this general.  I suggest to discuss
>> > specific functions you want to rename, if you have a list of them
>> > already.
>> 
>> Yes in comp-cstr.el the ones named without the doulbe dash and not
>> mentioned enywhere outside comp-cstr.el itself.  To a quick scan using
>> some scripting:
>> 
>> comp-cstr-intersection-make, comp-cstr-union-make, comp-cstr-symbol-p,
>> comp-cstr-union-1, comp-cstr-union-homogeneous,
>> comp-cstr-union-homogeneous-no-range, comp-cstr-sub-2, comp-cstr-add-2
>> comp-range-negation, comp-range-intersection, comp-range-union,
>> comp-intersect-typesets, comp-intersect-two-typesets,
>> comp-union-typesets comp-supertypes, comp-normalize-typeset,
>> comp-intersection-valsets comp-union-valsets, comp-normalize-valset,
>> comp-split-pos-neg comp-cstrs-homogeneous, comp-cstr-copy.
>> 
>> And similarly in comp.el:
>
> Which one(s) would you want to rename, to what names, and why?

I'd like to rename them all to the comp-- convention.  So it's even more
clear they are not for public use, the code will have an homogeneous
naming convention and I'll never have to raise again this discussion
each time I do some maintenance that requires renaming/removal.

Thanks

  Andrea

Re: Policy for obsolete funcitons

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 03 Nov 2023 06:33:29 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It's hard to tell something this general.  I suggest to discuss
> > specific functions you want to rename, if you have a list of them
> > already.
> 
> Yes in comp-cstr.el the ones named without the doulbe dash and not
> mentioned enywhere outside comp-cstr.el itself.  To a quick scan using
> some scripting:
> 
> comp-cstr-intersection-make, comp-cstr-union-make, comp-cstr-symbol-p,
> comp-cstr-union-1, comp-cstr-union-homogeneous,
> comp-cstr-union-homogeneous-no-range, comp-cstr-sub-2, comp-cstr-add-2
> comp-range-negation, comp-range-intersection, comp-range-union,
> comp-intersect-typesets, comp-intersect-two-typesets,
> comp-union-typesets comp-supertypes, comp-normalize-typeset,
> comp-intersection-valsets comp-union-valsets, comp-normalize-valset,
> comp-split-pos-neg comp-cstrs-homogeneous, comp-cstr-copy.
> 
> And similarly in comp.el:
> 
> comp-known-predicate-p, comp-pred-to-cstr,
> comp-block-preds, comp-gen-counter,
> comp-ensure-native-compiler,
> comp-equality-fun-p, comp-arithm-cmp-fun-p, comp-set-op-p,
> comp-assign-op-p, comp-call-op-p, comp-branch-op-p,
> comp-type-hint-p, comp-func-unique-in-cu-p, comp-function-pure-p,
> comp-alloc-class-to-container, comp-prettyformat-mvar,
> comp-prettyformat-insn, comp-log-func, comp-log-edges,
> comp-lex-byte-func-p, comp-spill-decl-spec, comp-spill-speed,
> comp-decrypt-arg-list, comp-add-func-to-ctxt,
> comp-intern-func-in-ctxt, comp-spill-lap, comp-lap-eob-p,
> comp-lap-fall-through-p, comp-bb-maybe-add, comp-callref,
> comp-new-frame, comp-emit, comp-emit-set-call, comp-copy-slot,
> comp-make-curr-block, comp-latch-make-fill, comp-emit-uncond-jump,
> comp-emit-cond-jump, comp-emit-handler, comp-limplify-listn,
> comp-new-block-sym, comp-fill-label-h,
> comp-jump-table-optimizable, comp-emit-switch,
> comp-emit-set-call-subr, comp-op-to-fun, comp-body-eff,
> comp-limplify-lap-inst, comp-emit-narg-prologue,
> comp-limplify-finalize-function, comp-emit-lambda-for-top-level,
> comp-limplify-top-level, comp-addr-to-bb-name,
> comp-limplify-block, comp-limplify-function, comp-limplify,
> comp-collect-mvars, comp-collect-rhs, comp-negate-arithm-cmp-fun,
> comp-reverse-arithm-fun, comp-emit-assume, comp-maybe-add-vmvar,
> comp-add-new-block-between, comp-cond-cstrs-target-mvar,
> comp-add-cond-cstrs-target-block, comp-add-cond-cstrs-simple,
> comp-add-cond-cstrs, comp-emit-call-cstr, comp-lambda-list-gen,
> comp-add-call-cstr, comp-add-cstrs, comp-collect-calls,
> comp-pure-infer-func, comp-ipa-pure, comp-clean-ssa,
> comp-compute-edges, comp-collect-rev-post-order,
> comp-compute-dominator-tree, comp-compute-dominator-frontiers,
> comp-log-block-info, comp-place-phis, comp-dom-tree-walker,
> comp-ssa-rename-insn, comp-ssa-rename, comp-finalize-phis,
> comp-remove-unreachable-blocks, comp-ssa, comp-copy-insn,
> comp-fwprop-prologue, comp-function-foldable-p,
> comp-function-call-maybe-fold, comp-fwprop-call, comp-fwprop-insn,
> comp-fwprop*, comp-rewrite-non-locals, comp-fwprop,
> comp-func-in-unit, comp-call-optim-form-call,
> comp-call-optim-func, comp-call-optim, comp-collect-mvar-ids,
> comp-dead-assignments-func, comp-dead-code,
> comp-form-tco-call-seq, comp-tco-func, comp-tco,
> comp-remove-type-hints-func, comp-remove-type-hints,
> comp-args-to-lambda-list, comp-compute-function-type,
> comp-finalize-container, comp-finalize-relocs,
> comp-compile-ctxt-to-file, comp-final1, comp-final,
> comp-eln-load-path-eff,
> comp-trampoline-filename, comp-make-lambda-list-from-subr,
> comp-trampoline-search, comp-trampoline-compile,
> comp-async-runnings, comp-effective-async-max-jobs,
> comp-accept-and-process-async-output, comp-run-async-workers.
> 
> I think they are all very internal to the compiler machinery, they
> tipically manipulate compiler specific kind of objects often requiring a
> very specific contex setup in order not to error.
> 
> I can't see a use for them as generic library.  I think they should move
> to the -- convention.

Phew! that's a lot of functions.  I guess we could rename them all on
master and wait for someone to holler?

Stefan, WDYT?

Re: Policy for obsolete funcitons

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Phew! that's a lot of functions.  I guess we could rename them all on
> master and wait for someone to holler?
>
> Stefan, WDYT?

Sounds good to me.

Re: Policy for obsolete funcitons

[Andrea Corallo]

Stefan Kangas <stefankangas@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Phew! that's a lot of functions.  I guess we could rename them all on
>> master and wait for someone to holler?
>>
>> Stefan, WDYT?
>
> Sounds good to me.

Cool, will do as soon as the scratch/comp-run affair is done.

Thanks

  Andrea