From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#23486: 25.0.93; Modules: features missing from make_function Date: Sun, 26 Mar 2017 20:02:08 +0000 Message-ID: References: <87inu21o35.fsf@users.sourceforge.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114b311442ca7c054ba7b4c8 X-Trace: blaine.gmane.org 1490558609 17342 195.159.176.226 (26 Mar 2017 20:03:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Mar 2017 20:03:29 +0000 (UTC) Cc: 23486@debbugs.gnu.org To: npostavs@users.sourceforge.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Mar 26 22:03:24 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1csENj-0003dI-Kn for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Mar 2017 22:03:19 +0200 Original-Received: from localhost ([::1]:42134 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csENp-0003Y1-JB for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Mar 2017 16:03:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54150) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csENW-0003Rv-PX for bug-gnu-emacs@gnu.org; Sun, 26 Mar 2017 16:03:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1csENS-0001gn-Kg for bug-gnu-emacs@gnu.org; Sun, 26 Mar 2017 16:03:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48017) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1csENS-0001gX-Hi for bug-gnu-emacs@gnu.org; Sun, 26 Mar 2017 16:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1csENS-0006ut-AA for bug-gnu-emacs@gnu.org; Sun, 26 Mar 2017 16:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Mar 2017 20:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23486 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23486-submit@debbugs.gnu.org id=B23486.149055854726541 (code B ref 23486); Sun, 26 Mar 2017 20:03:02 +0000 Original-Received: (at 23486) by debbugs.gnu.org; 26 Mar 2017 20:02:27 +0000 Original-Received: from localhost ([127.0.0.1]:46215 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1csEMt-0006u1-06 for submit@debbugs.gnu.org; Sun, 26 Mar 2017 16:02:27 -0400 Original-Received: from mail-wr0-f173.google.com ([209.85.128.173]:35316) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1csEMr-0006to-7t for 23486@debbugs.gnu.org; Sun, 26 Mar 2017 16:02:25 -0400 Original-Received: by mail-wr0-f173.google.com with SMTP id u1so28680560wra.2 for <23486@debbugs.gnu.org>; Sun, 26 Mar 2017 13:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n/wtF8ohszLLrKctCL4Imp0wfQBt81XdIGdc3y+W0ok=; b=BH0fzP59BzU13Z+c6VfFVSWTi4809RtLemHsibj8c5sSJTphq2yXBy0QKPA0w+okTn SVIL541V1M52jC9S/t0F2R4xhIXhrUXMctqzDbN5G9DWGJllMy8NvToTC+8D7GerzV/a EJPBI3/0NJgCvnA906rCVoiB95T47YkZgae2uzPPwxCZqWaVqUi6ZToggIxuinLN2kJS fn8xlHpvi64doFVYtiqlX2JxtTzaXJhX0RfABiryvXfLyd7ECHA5q3pZzF9LGs8T1xIJ sbCAlklpNY7nInvsHE6BhN0b3tuErioLUkBAyGsyu8cDqR8yETb54VO+sdOR2HKxP7ke JLkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n/wtF8ohszLLrKctCL4Imp0wfQBt81XdIGdc3y+W0ok=; b=TW8mbD0rb0iDyfuyYV9vbdDi/LAFgZli+4x889Ry5O1CT4IeyTT/+PzjWzj70OCLCM /t5Q/v3I+dP+VGhgD5kLvlkf5jfSP4yzmMq6oP+MFqyOB62G0UTXiqcKWgxYFcg0aBBT W1nB6iKGGD1woPIZAyyjgsm2X1fVYu1FDBW4ORU79FHF8cF2rbrbO0fP8lgsUzWOTU1i sZLgr4em4UMw8y9RRoWnl9A6VkrHBfOOwwtj3BK9E9M2q2lLNHJ7a6IvIP6sdSBPjMpE /tXwLqJpeODMe3C3+m3+XgwG9+i5kXUNgblMFOTaAnggObIijTX74de3EnEVjewO3SKd 5seA== X-Gm-Message-State: AFeK/H1Cm+SdeKleHDZFBqt2oQgHiD6pJkj84RUe4+qDekwyi2cujdyus7S9x63EfAcgH0cI6iOd3e3r6cOTWw== X-Received: by 10.28.220.139 with SMTP id t133mr1344220wmg.95.1490558539448; Sun, 26 Mar 2017 13:02:19 -0700 (PDT) In-Reply-To: <87inu21o35.fsf@users.sourceforge.net> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:130991 Archived-At: --001a114b311442ca7c054ba7b4c8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable schrieb am So., 11. Sep. 2016 um 16:56 Uhr= : > Philipp Stephani writes: > > > emacs_env::make_function lacks the following features supported by > > `defun': > > > > 1. Functions with both optional and rest arguments. > > 2. Specification of parameter names. > > 3. Integration with `help-function-arglist'. > > 4. Specification of interactive forms. > > 5. Specification of declare forms. > > 6. Docstrings containing null or non-Unicode characters. > > > > (6) is probably rather unimportant. (5) is probably not implementable > > (would require wrapping `defun', not `lambda'). (1)=E2=80=93(4) are mo= re severe > > and quite limit the usefulness of make_function right now; for a > > truly generic `defun'-like construct one currently has to eval a `defun= ' > > form wrapping another function. > > Shouldn't modules be providing a DEFUN-like construct instead? That is, > I thought the idea of modules was to enable writing primitive > subroutines. > I don't know what the idea of modules originally was. However, defun and DEFUN are composite operations: They create a function object (lambda) and provide an alias for it. Therefore they can't replace the more primitive operations. The current module interface design chooses to provide the primitive operation to make a function object and have the caller call defalias. That's a reasonable choice. > > > > > To solve (1)=E2=80=93(3), I'd propose replacing the "arity" arguments w= ith a > > true arglist specification. This could either be at the C level, e.g. > > > > ptrdiff_t num_mandatory_args, char** mandatory_arg_names, > > ptrdiff_t num_optional_args, char** optional_arg_names, > > char* rest_arg_name > > > > or by requiring to pass a Lisp argument list. > > > > To solve (4) I'd propose to pass another value for the interactive form= , > > probably as emacs_value* (to support non-interactive functions). > > > > As an alternative, if people feel this would require too many > > parameters, I'd propose reverting the change that adds the documentatio= n > > string. A docstring without arglist is not very useful. We could also > > remove the arity parameters and have the C function check the arity > > itself. > > I think adding "(fn ARG1 ARG2...)" to the docstring would solve (1)-(3). > That doesn't work, because Emacs ignores this syntax when the arguments are provided explicitly, and since a module function is just a (lambda (&rest args) ...) under the hood, the arglist is always just (&rest args). > What's lacking is a way to add this automagically like DEFUN does. And > getting the parameters in C variables like DEFUN would also be nice. > Maybe, but not for the module interface. The module interface explicitly only provides basic primitives, without macro magic or high-level functions. High-level functionality built on top of the primitives is out of scope. --001a114b311442ca7c054ba7b4c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


<npostavs@users.sourceforge.= net> schrieb am So., 11. Sep. 2016 um 16:56=C2=A0Uhr:
Philipp Stephani <p.stephani2@gmail.com> writes:

> emacs_env::make_function lacks the following features supported by
> `defun':
>
> 1. Functions with both optional and rest arguments.
> 2. Specification of parameter names.
> 3. Integration with `help-function-arglist'.
> 4. Specification of interactive forms.
> 5. Specification of declare forms.
> 6. Docstrings containing null or non-Unicode characters.
>
> (6) is probably rather unimportant.=C2=A0 (5) is probably not implemen= table
> (would require wrapping `defun', not `lambda').=C2=A0 (1)=E2= =80=93(4) are more severe
> and quite limit the usefulness of make_function right now; for a
> truly generic `defun'-like construct one currently has to eval a `= defun'
> form wrapping another function.

Shouldn't modules be providing a DEFUN-like construct instead?=C2=A0 Th= at is,
I thought the idea of modules was to enable writing primitive
subroutines.

I don&= #39;t know what the idea of modules originally was. However, defun and DEFU= N are composite operations: They create a function object (lambda) and prov= ide an alias for it. Therefore they can't replace the more primitive op= erations. The current module interface design chooses to provide the primit= ive operation to make a function object and have the caller call defalias. = That's a reasonable choice.
=C2=A0

>
> To solve (1)=E2=80=93(3), I'd propose replacing the "arity&qu= ot; arguments with a
> true arglist specification.=C2=A0 This could either be at the C level,= e.g.
>
>=C2=A0 =C2=A0 =C2=A0ptrdiff_t num_mandatory_args, char** mandatory_arg_= names,
>=C2=A0 =C2=A0 =C2=A0ptrdiff_t num_optional_args, char** optional_arg_na= mes,
>=C2=A0 =C2=A0 =C2=A0char* rest_arg_name
>
> or by requiring to pass a Lisp argument list.
>
> To solve (4) I'd propose to pass another value for the interactive= form,
> probably as emacs_value* (to support non-interactive functions).
>
> As an alternative, if people feel this would require too many
> parameters, I'd propose reverting the change that adds the documen= tation
> string.=C2=A0 A docstring without arglist is not very useful.=C2=A0 We= could also
> remove the arity parameters and have the C function check the arity > itself.

I think adding "(fn ARG1 ARG2...)" to the docstring would solve (= 1)-(3).

That doesn&= #39;t work, because Emacs ignores this syntax when the arguments are provid= ed explicitly, and since a module function is just a (lambda (&rest arg= s) ...) under the hood, the arglist is always just (&rest args).
<= div>=C2=A0
What's lacking is a way to add this automagically like DEFUN does.=C2= =A0 And
getting the parameters in C variables like DEFUN would also be nice.

--001a114b311442ca7c054ba7b4c8--