From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arthur Miller Newsgroups: gmane.emacs.devel Subject: Re: Declaring Lisp function types Date: Mon, 18 Mar 2024 10:58:05 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37551"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Mar 18 13:26:02 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rmC42-0009Z1-84 for ged-emacs-devel@m.gmane-mx.org; Mon, 18 Mar 2024 13:26:02 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rmC3L-0005sQ-4x; Mon, 18 Mar 2024 08:25:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rm9l2-0005tY-3z for emacs-devel@gnu.org; Mon, 18 Mar 2024 05:58:16 -0400 Original-Received: from mail-am6eur05olkn2069.outbound.protection.outlook.com ([40.92.91.69] helo=EUR05-AM6-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rm9kz-0004Ni-K5; Mon, 18 Mar 2024 05:58:15 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YHw5+wOPyfxLr5GCYQXE/amMPEzo8n+66ffmuqdr566/vMEFF12JwCczMbVSvM4BS32H9NG5rKzMbZ1OqDQWFDCxiM/r3uZS8EO37Dfb71/Ild9aD2gwCegzvspUjmPJmXuOURQBuCZoLF735FUd5FzKtpsGTAeXk2kBlNOAsE8WED6GJdy9X6HW+Q02nRqivTcLrfKUuadZ6cnc6mdlN7z2P8B/Fyb2SAGhG3OOXb0RXeBlu+Gt1KztLNzLTUXV1Aae/DypVJCnpbmBNtucvkLM5+78B2a197vYM+nHG45NjT4rA18xkqcVZiIoHswYdBZVk2aPCOG2gzdx7/rvsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=V9OGBVnWrfNf0FrQI2o12mdW+ga7/t8aTS2uQFOkKKM=; b=HooXJ81W1BdnSCRIo9uGoYIiDC1dQlltfRK4Y+XncMApdVSpKBcr56+eLVkyGxn7hb1/mxRldSeLsCOZWuSH6J0Borhjw2zlxxKhDPPTzSUPNt5OOLVYa92rbClW9YpOSDb8ADEjzYco6QcMCvMc0121kUb5OQJP9jLcdNSniWsk2UqIZd6SduQ08qSF4uKbGORAAUXb+HhlpYw39zAO8TzzPzR1BGoKYtCdLdmHQKEeaE5ZjWsaL9QJ25BQjjGbIxhI6oOfcJrkXLG6JwbaLcfmHxWX2r84zCP34jfIot+jbMKJuQlFxyj0QzcxhiibyufukgKTy3/aBRDURYL9xQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V9OGBVnWrfNf0FrQI2o12mdW+ga7/t8aTS2uQFOkKKM=; b=ppxBJ7K9MxGKl6RRC8WH0GJqLKWCih0ubXnw/uc/3qW6Y6rsbcQsOLSAFtDG8JrtEdqaCeAGsIjiP+x2ii98LRvh62g9z8/LCZnip+axHyLgyflx7Gb2gmwScZV90huv9cRGsCWpt1NaBHaD7KSSCT8i/31T4yLnYs8O/36BOVRE/JmWVBo85ILfLaZ+AMNFfwHK/Yxqxf0X0cirzIgngKoTDXYYBPaHdHUTbUaejEUX2xhFPkVGW55VuuzkhWRsewjbAmunNIzIorghPgk/e6y4enAtPI5XKFNCaBsgOiJXvGRH8CgrWreK702Os1a0U/3lDYd327gGFNsXz1WTdg== Original-Received: from DU2PR02MB10109.eurprd02.prod.outlook.com (2603:10a6:10:497::14) by AS8PR02MB6566.eurprd02.prod.outlook.com (2603:10a6:20b:25d::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.26; Mon, 18 Mar 2024 09:58:07 +0000 Original-Received: from DU2PR02MB10109.eurprd02.prod.outlook.com ([fe80::9549:47fe:660e:4d02]) by DU2PR02MB10109.eurprd02.prod.outlook.com ([fe80::9549:47fe:660e:4d02%4]) with mapi id 15.20.7386.025; Mon, 18 Mar 2024 09:58:07 +0000 In-Reply-To: (Andrea Corallo's message of "Mon, 18 Mar 2024 05:02:35 -0400") X-TMN: [iQXi3H+P2YsOY6gWAhU8T6dqUXfk86JzXHpbEWbr1YU=] X-ClientProxiedBy: MM0P280CA0005.SWEP280.PROD.OUTLOOK.COM (2603:10a6:190:a::35) To DU2PR02MB10109.eurprd02.prod.outlook.com (2603:10a6:10:497::14) X-Microsoft-Original-Message-ID: <87le6fdfpu.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU2PR02MB10109:EE_|AS8PR02MB6566:EE_ X-MS-Office365-Filtering-Correlation-Id: 95779372-4cf0-48f6-fd69-08dc4731e903 X-MS-Exchange-SLBlob-MailProps: gMiuAN0LASIUPaIMfCy1X1F+fVfuquBPA1wxDIK1J7iWq8Jl8P0UkpfT/0WEECoESmHIS+B3nAARStyGn0r+aeK8H5vJxGTNBbKafGvz/8gKMdFfCFLBEmgr/btbTfMIO+FZnU9adPRb3lXJxgwyjdgKlST0lwaTmxf/LRvgKZ2/PH/5LMTcQD0wiX7/euKZkTXy3jp41SQc5JJLbA6oGbuYcQqfuMqFXRdw4/LUAgxFH+JYBYKs7I0iqgbuun6Pvef7enzkP1se4gF3DY5gW5hDBbmnTj67UHGidODpMMZAr2r0irA+VVbImXVAXJDKccWYK+SCoAmyB6Qob+MgLpk7dac/+lNTjg15hjomaO4SBZ1zlUv9trHNqEk8ix61OAsdxjcIP+gv9BLEhJ725z+7hM1QgDpgX/JUKrwfrrVg3xCYg17nGNxvXM0mVYHfn6dXfy49IUZNOnASXRRm8TJG8cX52W5/1GV0pYvwlaLZ3Gp8LBi8+wtpGq54fDzp15anO0ZCM0QHOP5ot74Xz02EkYsuQXEN5DxXk/ZdI5bd600Vt0lFlilx8ObeyJcDIGmzSEdL4mVdnNepMoskhWcHlSPQSdRAISFjCXLy5qZaumXBkX8bGA+wEWMSdpyHPLaZ0x4UsYA3C+0u0Ebugc5r37/ACi05a2SGK4PxeflBS1z5wxRbLAsBFbQ/l7aVTNVR2PjenExies35AM9jfw== X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: x9VG3qIeDWmHXF9PRnsVgI0VW9Hxz1ZUd0XiBNxtaVrNxzdiO7H9a1f4eqawVasj5Tjfa+KNWfiZTBjLJ8WWqJa8XXSp47nE1W/0KtIKCmyPHSH63VLh/cWRGB2RTx8Zpq8SFYhm4/lNY6TLCAibLH4KZFZXYe//xsgZsRXNfn3ZolpR3LvjJdkCC6kwT35W4uPX+/DA/YYw4J/myOucyyeJsg7IK2+ptOgO76EpiKbDzf1gBCn0q59pcuBE8JU61Kqxc76uXjtLvhyiwDOdSU2cAItQN1cocMUfb+tymgrTxa2tJ3SpyH4PR0udAJVPV3mUda5X8f5C5ffVIw/rTOwWbkxY+3hwqwUCmnR2ACIJQklAYX2UmqbtXlv5DREq13ueGGoGnlpq0JWtdpNR4XsiMY1bySA+GHvvW+MVgkIGnBAmSmnQHton7OuGaHhH0kBrKtzLKtjD0Oc8/S/VaCKqinVrSh3mzMssLSvkWw8U84KGax/CZ9f8SEmoXdgRDdsnntbs4iLd/3UEFZFJ5WdRklnk45q1gsCgXDpmtCQYQmmUT+g9IL9D5PynpQ9F X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YWVNUnlXNTVoWnJhaDJqOFFzWFowampuM2lXbklHSVAxSnFSZmN1eEUybjdC?= =?utf-8?B?N25oU3pYT1Y1aURzR0M2WTcwblB6NnpMbFNyTklLcWRmVHhwUUE0WHFOMElE?= =?utf-8?B?a3dsNmg4QVFldmxySE1mK0pUb29wMFY0bUtCSHpEcUxkOXBaN0EvR0taYXRN?= =?utf-8?B?VlJnUzVRaVZmSzB5UzR2ODJlZGUyeU9xcDlQU1oxM1F4dmtCZlFxZVJ4U2xP?= =?utf-8?B?dHZLeXd2MldvaEZCdVc1dThTVE1ZYittWjFDZGd0OGhVdlNPcnBuMzR1bW1P?= =?utf-8?B?Mit2NDBhWnN0VVBlaU00ZlJURDN1eGJvaGg2ajVDMzJzSHd2SWdmM2J1WDBx?= =?utf-8?B?YzJ4UDc3UndIZ2dMdnBoQWFmY0pXVUlqVmppMUh6RTF4WkFQOWV6TXFWbERn?= =?utf-8?B?WVBiYkg5RkErTldJdGU3d0RlenRCcmQ5K0t2QkNBeVJLZmx1VjNDNmIrdHVh?= =?utf-8?B?K3A4MXRJalZRaGxFTmZMdk9PQ3cvYkZ3UFlib2pVNHZuZkE2VnFFNG9BU3Zw?= =?utf-8?B?bXl4d0RIalFGeHJWTURBWlJKeW05dmowRTZHZkxBWlBVV2ZSaW5oc2J3RmFJ?= =?utf-8?B?MFVSMXY3TjlFbmluRXFQaFBvdHp2dDd2M0FSL0pGR0pKUWN4U2lubkx1dHdo?= =?utf-8?B?UlVWTkJIcXIyRXBIck85cWg0RlBaeDc1d1YxTE X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-ab7de.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 95779372-4cf0-48f6-fd69-08dc4731e903 X-MS-Exchange-CrossTenant-AuthSource: DU2PR02MB10109.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Mar 2024 09:58:07.1181 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR02MB6566 Received-SPF: pass client-ip=40.92.91.69; envelope-from=arthur.miller@live.com; helo=EUR05-AM6-obe.outbound.protection.outlook.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 18 Mar 2024 08:25:15 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:317165 Archived-At: Andrea Corallo writes: > Arthur Miller writes: > >> Stefan Monnier via "Emacs development discussions." >> writes: >> >>>>> (declaim (ftype (function (integer integer) integer) sum)) >>>>> ;; ^^inputs ^^output [optional] >>>>> (defun sum (a b) >>>>> (declare (integer a b)) >>>>> (+ a b)) >>>> >>>> Non-starter for me: the separation into two steps makes it unclear wha= t >>>> the declaration applies to (e.g. when re-running the above code, does >>>> the `declaim` apply to the old definition (the one active when the >>>> `declaim` is executed)=C2=AE the the one that's about to be installed)= ? >>>> >>>>> ;;2 >>>>> (defun sum (a b) >>>>> (declare (integer a b)) >>>>> (+ a b)) >>>> >>>> None starter because of how we defined `declare`, where we'd have to >>>> define every existing type as a valid declaration idenitifer. >>>> >>>>> ;;3 through 'defstar' (a CL library not in the standard) >>>>> (defun* sum ((a integer) (b integer)) >>>>> (+ a b)) >>>>> ;;4 again through 'defstar' >>>>> (defun* (sum -> integer) ((a integer) (b integer)) >>>>> (+ a b)) >>>> >>>> Acceptable, with some tweaks to better fit my favorite bikeshed color. >>>> >>>>> (defun sum (a b) >>>>> (declare (ftype (function (integer integer) integer))) >>>>> (+ a b)) >>>> >>>> The `f` of `ftype` is redundant with the following `function`, so we >>>> could shorten that to: >>>> >>>> (defun sum (a b) >>>> (declare (ftype (integer integer) integer)) >>>> (+ a b)) >>>> >>>>> (defun sum (a b) >>>>> (declare (function (integer integer) integer)) >>>>> (+ a b)) >>>> >>>> It's cute, I guess. Whether to prefer `function`, `ftype`, or Adam's = `type`, >>>> is largely a "bikeshed color" choice. I do prefer the latter two >>>> because we already know that this is a function, whereas we don't know >>>> that this is a *type* (and they're shorter, to boot). >>>> >>>> Later you said: >>>>> Fact is, we already use the form (function (ATYPES) RTYPE) as type >>>>> specifier for functions. So (ftype (function (ATYPES) RTYPE)) would = be >>>>> the most correct form semantically, where `ftype` (or `type` or reall= y >>>>> what we prefer) would be the declaration which takes the type specifi= er >>>>> as argument. >>>> >>>> Of course (declare (ftype (integer integer) integer)) >>>> would still end up generating something like >>>> >>>> (foo-declare-type 'sum '(function (integer integer) integer)) >>> >>>My fear it's this is a bit more convoluted and this extra step makes it >>>less understandable/justifiable. I like the symmetry of having >>>'function' both in the input (the declaration) and the output (the final >>>type itself). Maybe my background as physicist makes symmetry too >>>central for me? :) >>> >>>> so I see no semantic issue with using `ftype` or `type` here, unless >>>> there are functions whose type could take another form than (function >>>> )? Are you thinking of types like >>>> (or (function (int) int) (function (float) float))? >>> >>>That's a good example why it would be good to be able to accept the type >>>specifier as a declaration with no tricks. On the specific case I'm not >>>sure we want to support this in the inner machinery (at least for now). >>> >>>> More important I think is to document what such annotations mean and >>>> what they should look like (currently, this is not super important, >>>> because the annotations live together with the code that uses them, bu= t >>>> if we move them outside of `comp.el`, the "contract" needs to be made >>>> more explicit). >>>> >>>> - How they interact with `&optional` and `&rest` (or even `&key` for >>>> `c-defun`). >>> >>>ATM we already support in type specifiers `&optional` and `&rest`: >>> >>>(subr-type (native-compile '(lambda (x &optional y &rest z)))) =3D> >>>(function (t &optional t &rest t) null) >>> >>>Not sure we want to handle &key as well as it looks to me not very >>>native to the elisp machinery. OTOH cl-defun just expands to the native >>>elisp call convention. >>> >>>> - What will/could happen if one of the arguments does not have the >>>> specified type? >>> >>>I think if ones does a declaration has to declare the type of all >>>arguments (rest should be optional). >>> >>>> - What will/could happen if the result does not have the >>>> specified type? >>> >>>I think we want to complete it with the inferred return type if we have >>>it or t otherwise. >>> >>>> - Do we have types to say "arg unused" or "no return value"? >>> >>>We don't have "arg unused" because the function type (or signature) is >>>like the contract with the outside word, it should not matter how (and >>>if) and arg is used inside. >>> >>>OTOH we have "no return value" and it's nil >>> >>>(subr-type (native-compile '(lambda (x) (error x)))) =3D> >>>(function (t) nil) >>> >>>> - Can we have higher-order function types, like >>>> >>>> (function (proc (function (proc string) void)) void) >>>> >>>> and if so, again, what does it mean in terms of what can happen if t= he >>>> runtime values don't actually match the announced types (e.g. what >>>> happens (and when) if we pass a function that has the "wrong type")? >>> >>>I don't kwnow if we want to allow this to be future proof, ATM certanly >>>the compiler does not use it and I don't think it could help code >>>generation. OTOH might be nice for documentation? >>> >>>As a note: AFAIR SBCL doesn't go beyond something like: >>>(function (integer function) function) >>> >>>That if arguments/ret values are functions it forgets the inner details >>>of their type specifier. >>> >>>Anyway I certanly agree we should better document this once it's shaped, >>>and I'll try my best. >>> >>>But generally speaking I've the feeling there might be other cases we >>>don't see ATM where accepting directly the type specifier as valid >>>declaration graciously/naturally solves potential issues we could hit >>>otherwise. >>> >>>Thanks >> >> Please, if you can, just (re)use SBCL syntax. It makes life easier >> for those who are already familiar. Those who are not have to learn >> something new anyway, so for them it does not matter. >> >> Great work, thank you working so much with this. > > Hi Arthur, > > I agree on the principle, but unfortunately as mentioned using the CL > syntax in the Emacs declare machinery is problematic for how this second > one is constructed. I think is not a realistic option. Allright, that is unfortunate, but I understand, thanks for the clarificati= on. /best regards > Thanks > > Andrea