unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Qiantan Hong <qthong@stanford.edu>
Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Re: Naming FCRs
Date: Sun, 26 Dec 2021 23:12:48 -0500	[thread overview]
Message-ID: <jwv7dbqem7r.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <591A9AE3-3B90-4C15-BBC5-E2710EF89075@stanford.edu> (Qiantan Hong's message of "Mon, 27 Dec 2021 02:33:08 +0000")

Po Lu [2021-12-27 09:35:42] wrote:
> How about "functions-with-record"?

Which we'd abbreviate to FWR pronounced "fower", as in "Wow!  this
concept is really fowerful!" ?

There's something do it, tho the implementation doesn't really add any
record to the functions, it just uses the existing representation of
a function.  So maybe a more fitting name would be "functions as records",
abbreviated "far", as in "Wow!  This name is really far-fetched!" ?

Qiantan Hong [2021-12-27 02:33:08] wrote:
> I believe MIT Scheme has what exactly you described, and is called
> “apply-hook”, because it’s like hacking apply so it knows how to call
> an ordinary datum like a function.

These apply hooks are more like CL's funcallable objects, which we can
already simulate in ELisp with a symbol.
Basically `set-apply-hook-procedure!` is `fset`.

In contrast, FCRs are designed to be just normal closures, except they
come with a type and you get direct access from outside the function to
some of the vars that are closed over (and just as with closures, you
don't get to change the code associated with an FCR object).

By design, calling an FCR should not incur *any* overhead compared to
calling the same thing defined as a "normal" function.

Bob Rogers [2021-12-26 19:46:39] wrote:
> Without looking at the code, this sounds more like a closure to me.

Right, I rarely distinguish "closures" from "functions", but indeed,
these are more closures in that their "heap object" characteristics are
made more visible.

> Since the slots are accessible outside the function, that would make it
> a "transparent closure" . . . but I like the internal dissonance of
> "open closure" better.  ;-}

I like that, thank you.


        Stefan




  reply	other threads:[~2021-12-27  4:12 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-26 22:04 Naming FCRs Stefan Monnier
2021-12-26 22:29 ` Dmitry Gutov
2021-12-27 18:55   ` Stefan Monnier
2021-12-28  0:31     ` Dmitry Gutov
2021-12-27  0:46 ` Bob Rogers
2021-12-28 13:11   ` xenodasein--- via Emacs development discussions.
2021-12-29 16:33   ` Lars Ingebrigtsen
2022-01-04 20:31     ` Stefan Monnier
2022-01-11  3:25       ` Filipp Gunbin
2022-01-11  3:44         ` Stefan Monnier
2022-01-12  4:56           ` Richard Stallman
2022-01-12 15:10             ` Stefan Monnier
2021-12-27  1:35 ` Po Lu
2021-12-27  2:33   ` Qiantan Hong
2021-12-27  4:12     ` Stefan Monnier [this message]
2021-12-27  7:33       ` tomas
2021-12-29  1:09         ` Phil Sainty
2021-12-28  4:19   ` Richard Stallman
2021-12-28  5:43     ` Po Lu
2021-12-28 11:24       ` Andreas Schwab
2021-12-28 17:28         ` Stefan Monnier
2021-12-30 10:35           ` Andreas Schwab
2021-12-27  4:15 ` Richard Stallman
2021-12-27  5:46   ` LdBeth
2021-12-27 19:48     ` Stefan Monnier
2021-12-27  4:38 ` Jim Porter
     [not found]   ` <jwvczlheu3o.fsf-monnier+emacs@gnu.org>
2021-12-28 18:35     ` Jim Porter
2021-12-29  1:02       ` Phil Sainty
2021-12-29 16:19       ` Richard Stallman
2021-12-29 16:43         ` [External] : " Drew Adams
2021-12-29 19:01         ` Stefan Monnier
2021-12-30  2:54           ` LdBeth
2021-12-30  4:28           ` Richard Stallman
2021-12-30  8:43             ` tomas
2021-12-30 10:15               ` Tomas Hlavaty
2021-12-30 14:00                 ` Stefan Monnier
2021-12-30 18:46                   ` Tomas Hlavaty
2021-12-31  4:26                   ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwv7dbqem7r.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=emacs-devel@gnu.org \
    --cc=qthong@stanford.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).