unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Naming FCRs
@ 2021-12-26 22:04 Stefan Monnier
  2021-12-26 22:29 ` Dmitry Gutov
                   ` (4 more replies)
  0 siblings, 5 replies; 38+ messages in thread
From: Stefan Monnier @ 2021-12-26 22:04 UTC (permalink / raw)
  To: emacs-devel

Hi,

As the year is getting near its end, I figure it's a good time to open
a competition to choose a name for the thingy I've been playing with in
`scratch/fcr`.

The current name stands for FunCallableRecords, but this name is clearly
wrong, since it makes it sound like I'm defining a special kind of
record that just happen to be callable as a function, whereas FCRs are
really fundamentally functions that happen to have slots and a type,
like records.

So I'm asking here for suggestions of a better name.
Names that are technically "acceptable" but aren't very good:
- propertized functions (since the slots can also be called properties).
- translucent functions (since you can extract information from FCRs
  without having to call them, so they're less opaque).
- categorized functions (since "category" is similar to "type").
- functions with slots.
- record-like functions.
- Monomaniac objects (since they're a bit like OO-style objects but
  limited to have only exactly one method).
A good name would ideally come with a fun abbreviation.
Feel free to send me your ideas,


        Stefan




^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  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-27  0:46 ` Bob Rogers
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 38+ messages in thread
From: Dmitry Gutov @ 2021-12-26 22:29 UTC (permalink / raw)
  To: monnier, emacs-devel

On 27.12.2021 01:04, Stefan Monnier wrote:
> - Monomaniac objects (since they're a bit like OO-style objects but
>    limited to have only exactly one method).

A function with a value attached sounds like a "method".

Not too fun, though.

I also looked at the branch briefly -- if it's what it sounded like then 
you might be setting up a new "Callable protocol" which can allow any 
object to serve as a function, not just records? Like how maps are 
callable in Clojure.



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Naming FCRs
  2021-12-26 22:04 Naming FCRs Stefan Monnier
  2021-12-26 22:29 ` 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
  2021-12-27  1:35 ` Po Lu
                   ` (2 subsequent siblings)
  4 siblings, 2 replies; 38+ messages in thread
From: Bob Rogers @ 2021-12-27  0:46 UTC (permalink / raw)
  To: monnier; +Cc: emacs-devel

   From: Stefan Monnier <monnier@iro.umontreal.ca>
   Date: Sun, 26 Dec 2021 17:04:25 -0500

   Hi,

   As the year is getting near its end, I figure it's a good time to open
   a competition to choose a name for the thingy I've been playing with in
   `scratch/fcr`.

   The current name stands for FunCallableRecords, but this name is clearly
   wrong, since it makes it sound like I'm defining a special kind of
   record that just happen to be callable as a function, whereas FCRs are
   really fundamentally functions that happen to have slots and a type,
   like records . . .

Without looking at the code, this sounds more like a closure to me.
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.  ;-}

					-- Bob Rogers
					   http://www.rgrjr.com/



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-26 22:04 Naming FCRs Stefan Monnier
  2021-12-26 22:29 ` Dmitry Gutov
  2021-12-27  0:46 ` Bob Rogers
@ 2021-12-27  1:35 ` Po Lu
  2021-12-27  2:33   ` Qiantan Hong
  2021-12-28  4:19   ` Richard Stallman
  2021-12-27  4:15 ` Richard Stallman
  2021-12-27  4:38 ` Jim Porter
  4 siblings, 2 replies; 38+ messages in thread
From: Po Lu @ 2021-12-27  1:35 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> The current name stands for FunCallableRecords, but this name is clearly
> wrong, since it makes it sound like I'm defining a special kind of
> record that just happen to be callable as a function, whereas FCRs are
> really fundamentally functions that happen to have slots and a type,
> like records.

How about "functions-with-record"?



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-27  1:35 ` Po Lu
@ 2021-12-27  2:33   ` Qiantan Hong
  2021-12-27  4:12     ` Stefan Monnier
  2021-12-28  4:19   ` Richard Stallman
  1 sibling, 1 reply; 38+ messages in thread
From: Qiantan Hong @ 2021-12-27  2:33 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel@gnu.org

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.

Best,
Qiantan

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-27  2:33   ` Qiantan Hong
@ 2021-12-27  4:12     ` Stefan Monnier
  2021-12-27  7:33       ` tomas
  0 siblings, 1 reply; 38+ messages in thread
From: Stefan Monnier @ 2021-12-27  4:12 UTC (permalink / raw)
  To: Qiantan Hong; +Cc: emacs-devel@gnu.org

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




^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-26 22:04 Naming FCRs Stefan Monnier
                   ` (2 preceding siblings ...)
  2021-12-27  1:35 ` Po Lu
@ 2021-12-27  4:15 ` Richard Stallman
  2021-12-27  5:46   ` LdBeth
  2021-12-27  4:38 ` Jim Porter
  4 siblings, 1 reply; 38+ messages in thread
From: Richard Stallman @ 2021-12-27  4:15 UTC (permalink / raw)
  To: monnier; +Cc: emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The current name stands for FunCallableRecords, but this name is clearly
  > wrong, since it makes it sound like I'm defining a special kind of
  > record that just happen to be callable as a function, whereas FCRs are
  > really fundamentally functions that happen to have slots and a type,
  > like records.

I think I understand what that means, but I'm not confident I do.
Would you please show us an example to make the meaning clear?

For instance, is this basically equivalent to a closure that you could
create with `lambda'?  If so, what is the benefit of adding this
construct?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-26 22:04 Naming FCRs Stefan Monnier
                   ` (3 preceding siblings ...)
  2021-12-27  4:15 ` Richard Stallman
@ 2021-12-27  4:38 ` Jim Porter
       [not found]   ` <jwvczlheu3o.fsf-monnier+emacs@gnu.org>
  4 siblings, 1 reply; 38+ messages in thread
From: Jim Porter @ 2021-12-27  4:38 UTC (permalink / raw)
  To: monnier, emacs-devel

On 12/26/2021 2:04 PM, Stefan Monnier wrote:
> - Monomaniac objects (since they're a bit like OO-style objects but
>    limited to have only exactly one method).

Perhaps "function object"? Usually, a function object is a callable 
entity that has state associated with it. On the other hand, the 
"associated state" is fuzzy enough that a reader might think "function 
object" includes closures, since those contain state too. Maybe that's 
ok, or maybe that's confusing; I guess it depends on how (if at all) 
FunCallableRecords relate to closures.

> A good name would ideally come with a fun abbreviation.
> Feel free to send me your ideas,

Or how about a "structured function", since it's a function with some 
additional structure, i.e. the record slots? A "strunction"? Ok, maybe 
that last one leans a little too far towards "fun" and not enough 
towards "comprehensible"...

- Jim



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-27  4:15 ` Richard Stallman
@ 2021-12-27  5:46   ` LdBeth
  2021-12-27 19:48     ` Stefan Monnier
  0 siblings, 1 reply; 38+ messages in thread
From: LdBeth @ 2021-12-27  5:46 UTC (permalink / raw)
  To: monnier; +Cc: rms, emacs-devel


> The current name stands for FunCallableRecords, but this name is clearly
> wrong, since it makes it sound like I'm defining a special kind of
> record that just happen to be callable as a function, whereas FCRs are
> really fundamentally functions that happen to have slots and a type,
> like records.

I'm not sure, is this feature similar to "Flavors" or "Entifies"
avaliable from Lisp Machine?

To quote from Lisp Machine Manual

> An entity is almost the same thing as a closure; an entity behaves
> just like a closure when applied, but it has a recognizably
> different data type which allows certain parts of the system such as
> the printer and describe to treat it differently. A dosurc is simply
> a kind of ·function, but an entity is assumed to be a
> message-receiving object. Thus, when the Lisp printer (sec section
> 23.1, page 506) is given a closure, it prints a simple textual
> representation, but when it is handed an entity~ it sends the entity
> a :print-self message, which the entity is expected to handle. The
> describe function (sec page 791) also sends entities messages when
> it is handed them. So when you want to make a message-receiving
> object out of a closure, as described on page 407, you should usc an
> entity instead.


-- 
LDB



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-27  4:12     ` Stefan Monnier
@ 2021-12-27  7:33       ` tomas
  2021-12-29  1:09         ` Phil Sainty
  0 siblings, 1 reply; 38+ messages in thread
From: tomas @ 2021-12-27  7:33 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]

On Sun, Dec 26, 2021 at 11:12:48PM -0500, Stefan Monnier wrote:

[...]

> 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.

Happened to me, too... so I went out there trolling the tesauri in the
Interwebs, specifically for "antonyms of closure". The net is weird, it
has answers to such a crazy question. Loads of answers:

Some which jumped at me for different reasons:

 - opening (too generic, but...)
 - continuation (not proposing that, it's taken, but... wow ;-)
 - disclosure (that one has a nice ring to it)
 - survival (nah, but... ;-)
 - preservation
 - continuance
 - continuity
 - introduction
 - can of worms (!)

This isn't meant as direct proposals (in fact, the "continuation"
flavoured ones are dangerous, since that has a clear, different
connotation in Lispy worlds). It's rather meant as "inspiring material".
The only direct candidate I somewhat like in that list would be
"disclosure" -- I'd expect it to recall the association of "closure",
helping the user's intuition. Like a closure, but you have access to
some of its knobs from the outside.

Cool idea, BTW :)

Cheers

[1] https://thesaurus.plus/antonyms/closure
[2] https://www.wordhippo.com/what-is/the-opposite-of/closure.html
[3] https://www.powerthesaurus.org/closure/antonyms

-- 
tomás

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-26 22:29 ` Dmitry Gutov
@ 2021-12-27 18:55   ` Stefan Monnier
  2021-12-28  0:31     ` Dmitry Gutov
  0 siblings, 1 reply; 38+ messages in thread
From: Stefan Monnier @ 2021-12-27 18:55 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: emacs-devel

Dmitry Gutov [2021-12-27 00:29:29] wrote:
> On 27.12.2021 01:04, Stefan Monnier wrote:
>> - Monomaniac objects (since they're a bit like OO-style objects but
>>    limited to have only exactly one method).
> A function with a value attached sounds like a "method".

Hmm... in my mind a method is more like a function attached to a (set
of) objects.

> Not too fun, though.

There's a fair bit of potential by playing with the "meth" prefix, I think.

> I also looked at the branch briefly -- if it's what it sounded like then you
> might be setting up a new "Callable protocol" which can allow any object to
> serve as a function, not just records? Like how maps are callable
> in Clojure.

Not really.  It's more about adding object characteristics to functions than
adding function characteristics to objects.


        Stefan




^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-27  5:46   ` LdBeth
@ 2021-12-27 19:48     ` Stefan Monnier
  0 siblings, 0 replies; 38+ messages in thread
From: Stefan Monnier @ 2021-12-27 19:48 UTC (permalink / raw)
  To: LdBeth; +Cc: rms, emacs-devel

> I'm not sure, is this feature similar to "Flavors" or "Entities"
> avaliable from Lisp Machine?

Flavors are more like traditional OO objects, but yes FCRs are very
similar to LML's "entities" (and "closures").  Thanks, I didn't know
this part of LML yet.


        Stefan




^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-27 18:55   ` Stefan Monnier
@ 2021-12-28  0:31     ` Dmitry Gutov
  0 siblings, 0 replies; 38+ messages in thread
From: Dmitry Gutov @ 2021-12-28  0:31 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

On 27.12.2021 21:55, Stefan Monnier wrote:
> Dmitry Gutov [2021-12-27 00:29:29] wrote:
>> On 27.12.2021 01:04, Stefan Monnier wrote:
>>> - Monomaniac objects (since they're a bit like OO-style objects but
>>>     limited to have only exactly one method).
>> A function with a value attached sounds like a "method".
> 
> Hmm... in my mind a method is more like a function attached to a (set
> of) objects.

In Ruby object model anyway, a Method is a method bound to a particular 
instance of a class (https://ruby-doc.org/core-2.7.1/Method.html), 
whereas for methods not bound to any given value the term is "unbound 
method" (https://ruby-doc.org/core-2.7.1/UnboundMethod.html).

Though I suppose one semantic distinction is that when one thinks about 
methods, some "class" is present in the context, and one would usually 
expect that said class should contain other methods as well (i.e. the 
value that is said method is bound to, can respond to some other 
methods), which matters to how one organizes code. But... that's not 
necessarily true when one considers CLOS or our cl-defmethod, right?

Anyway, perhaps an unambiguous term could be "bound method".

Or if we take JavaScript, the return value of Function#bind 
(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/bind) 
is described as "bound function". But JS uses the word "function" for 
both "normal" functions and methods, so I suppose "bound method" would 
be less ambiguous.

On the third hand, the adjective hints at some action of "binding" which 
is supposed to produce such values, which is true of both Ruby and JS 
examples. If there is nothing similar going on in fcr.el, maybe such 
term wouldn't be ideal.

>> Not too fun, though.
> 
> There's a fair bit of potential by playing with the "meth" prefix, I think.

Following the glorious tradition of "gimp", "git" and "slime".

>> I also looked at the branch briefly -- if it's what it sounded like then you
>> might be setting up a new "Callable protocol" which can allow any object to
>> serve as a function, not just records? Like how maps are callable
>> in Clojure.
> 
> Not really.  It's more about adding object characteristics to functions than
> adding function characteristics to objects.

All right, then.



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-27  1:35 ` Po Lu
  2021-12-27  2:33   ` Qiantan Hong
@ 2021-12-28  4:19   ` Richard Stallman
  2021-12-28  5:43     ` Po Lu
  1 sibling, 1 reply; 38+ messages in thread
From: Richard Stallman @ 2021-12-28  4:19 UTC (permalink / raw)
  To: Po Lu; +Cc: monnier, emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

The term "function with record" has a basic drawback: it describes what
these things are built out of, not what they do.

Before adding this feature, we should consider whether it would really
add significant functionality to Emacs.  I tend to think that it
doesn't, because they are so similar to the closures we already have.

Can anyone make an argument that having functions-with-records as well
as closures would be significantly better than having only closures?
If not, we may as well leave this alone.

But if there is a significant benefit in having
functions-with-records, let's give them a name which is not a
description of theie low level implementation.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-28  4:19   ` Richard Stallman
@ 2021-12-28  5:43     ` Po Lu
  2021-12-28 11:24       ` Andreas Schwab
  0 siblings, 1 reply; 38+ messages in thread
From: Po Lu @ 2021-12-28  5:43 UTC (permalink / raw)
  To: Richard Stallman; +Cc: monnier, emacs-devel

Richard Stallman <rms@gnu.org> writes:

> The term "function with record" has a basic drawback: it describes what
> these things are built out of, not what they do.

Isn't the whole point of this feature "they're like closures but you can
introspect the environment?"



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-28  5:43     ` Po Lu
@ 2021-12-28 11:24       ` Andreas Schwab
  2021-12-28 17:28         ` Stefan Monnier
  0 siblings, 1 reply; 38+ messages in thread
From: Andreas Schwab @ 2021-12-28 11:24 UTC (permalink / raw)
  To: Po Lu; +Cc: emacs-devel, Richard Stallman, monnier

On Dez 28 2021, Po Lu wrote:

> Isn't the whole point of this feature "they're like closures but you can
> introspect the environment?"

If that's the only point, why can't we add that introspection facility
to closures?

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-27  0:46 ` Bob Rogers
@ 2021-12-28 13:11   ` xenodasein--- via Emacs development discussions.
  2021-12-29 16:33   ` Lars Ingebrigtsen
  1 sibling, 0 replies; 38+ messages in thread
From: xenodasein--- via Emacs development discussions. @ 2021-12-28 13:11 UTC (permalink / raw)
  To: emacs-devel

Dec 27, 2021, 03:46 by Bob Rogers:

> ...
> Without looking at the code, this sounds more like a closure to me.
> 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.  ;-}
>
>  -- Bob Rogers
>  > http://www.rgrjr.com/
>

+1




^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-28 11:24       ` Andreas Schwab
@ 2021-12-28 17:28         ` Stefan Monnier
  2021-12-30 10:35           ` Andreas Schwab
  0 siblings, 1 reply; 38+ messages in thread
From: Stefan Monnier @ 2021-12-28 17:28 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Po Lu, Richard Stallman, emacs-devel

Andreas Schwab [2021-12-28 12:24:32] wrote:
> On Dez 28 2021, Po Lu wrote:
>> Isn't the whole point of this feature "they're like closures but you can
>> introspect the environment?"
> If that's the only point, why can't we add that introspection facility
> to closures?

That's what it does ;-)


        Stefan




^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
       [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
  0 siblings, 2 replies; 38+ messages in thread
From: Jim Porter @ 2021-12-28 18:35 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Emacs developers

(Re-adding the mailing list, since it got removed.)

On Mon, Dec 27, 2021 at 11:21 AM Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>
> >> - Monomaniac objects (since they're a bit like OO-style objects but
> >>    limited to have only exactly one method).
> > Perhaps "function object"?
>
> That suffers from the same problem as FCR in that it suggests that the
> primary characteristic is "an object" rather than "a function".

For me at least, the benefit of "function object" is that it's already
the established name for something like this in the C++ world[1]. When
I think of a function object, I think (in C++) of a class/struct that
holds some data but exists primarily to be used as a function
(typically by passing it to a metafunction).

However, for non-C++ programmers, I can see how it would give the
wrong connotation.

> > On the other hand, the "associated state" is fuzzy enough that
> > a reader might think "function object" includes closures, since those
> > contain state too.
>
> Plain old `lambda` is a strict subset of `fcr-lambda`, so yes, the usual
> closures are just the most basic kinds of FCRs (FCRs introduce a type
> hierarchy just as is done for defstructs and defclass and plain old
> closures can be compared to the "object" class that sits at the root).

Ok, in that case it sounds to me like the ideal name would give the
reader the sense that this is a generalization of a closure. One
possibility would be a "bound function", since you're binding some
data to it. Then lambdas could be described as "lexically-bound
functions" which, if I'm understanding FCRs correctly, makes the
relationship between the two reasonably clear.

As for a fun name derived from that, maybe "bofun"? It sounds a bit
like bosun, someone "responsible for the components of a ship's hull",
and you could probably make a vague analogy to FCRs being responsible
for their associated records. Bofun also apparently means "fauna" in
the Yoruba language.

[1] Let's ignore the term "functor", which could confuse people with a
mathematics background.

> >> A good name would ideally come with a fun abbreviation.
> >> Feel free to send me your ideas,
> > Or how about a "structured function",
>
> I like that one, thanks.
>
> > A "strunction"? Ok, maybe that last one leans a little too far towards
> > "fun" and not enough towards "comprehensible"...
>
> Struf?



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-28 18:35     ` Jim Porter
@ 2021-12-29  1:02       ` Phil Sainty
  2021-12-29 16:19       ` Richard Stallman
  1 sibling, 0 replies; 38+ messages in thread
From: Phil Sainty @ 2021-12-29  1:02 UTC (permalink / raw)
  To: Jim Porter; +Cc: Stefan Monnier, Emacs developers

On 2021-12-29 07:35, Jim Porter wrote:
> For me at least, the benefit of "function object" is that it's
> already the established name for something like this in the C++
> world[1]. When I think of a function object, I think (in C++)
> of a class/struct that holds some data but exists primarily to
> be used as a function (typically by passing it to a
> metafunction).
> 
> However, for non-C++ programmers, I can see how it would give
> the wrong connotation.

Yes, in a lisp context I think it would just be confusing?
Functions are already (lisp) objects.  The specific object type
may vary from function to function, but if someone said "function
object" to me I wouldn't think they meant anything more than one
of the existing types of object that a function can be.





^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-27  7:33       ` tomas
@ 2021-12-29  1:09         ` Phil Sainty
  0 siblings, 0 replies; 38+ messages in thread
From: Phil Sainty @ 2021-12-29  1:09 UTC (permalink / raw)
  To: tomas; +Cc: emacs-devel

On 2021-12-27 20:33, tomas@tuxteam.de wrote:
> The only direct candidate I somewhat like in that list would be
> "disclosure" -- I'd expect it to recall the association of "closure",
> helping the user's intuition. Like a closure, but you have access to
> some of its knobs from the outside.

That's about as perfect as you can get, to my mind.

A closure which can disclose its environment seems like a precise
description of the feature, from what I've understood.





^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  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
  1 sibling, 2 replies; 38+ messages in thread
From: Richard Stallman @ 2021-12-29 16:19 UTC (permalink / raw)
  To: Jim Porter; +Cc: monnier, emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I think we should extend the functionality of closures by providing a
way to access the bound variables in them.  Then we won't need to make
Emacs Lisp more complicated with a new data type, because ordinary
closures will do this job too.

Does anyone argue that it is important to distinguish between closures
that permit access and closures that don't permit access?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  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
  1 sibling, 1 reply; 38+ messages in thread
From: Lars Ingebrigtsen @ 2021-12-29 16:33 UTC (permalink / raw)
  To: Bob Rogers; +Cc: monnier, emacs-devel

Bob Rogers <rogers-emacs@rgrjr.homedns.org> writes:

> Without looking at the code, this sounds more like a closure to me.
> 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.  ;-}

"Open closure" gets my vote.  🙃

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 38+ messages in thread

* RE: [External] : Re: Naming FCRs
  2021-12-29 16:19       ` Richard Stallman
@ 2021-12-29 16:43         ` Drew Adams
  2021-12-29 19:01         ` Stefan Monnier
  1 sibling, 0 replies; 38+ messages in thread
From: Drew Adams @ 2021-12-29 16:43 UTC (permalink / raw)
  To: rms@gnu.org, Jim Porter; +Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org

> I think we should extend the functionality of closures by providing a
> way to access the bound variables in them.  Then we won't need to make
> Emacs Lisp more complicated with a new data type, because ordinary
> closures will do this job too.

+1.

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  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
  1 sibling, 2 replies; 38+ messages in thread
From: Stefan Monnier @ 2021-12-29 19:01 UTC (permalink / raw)
  To: Richard Stallman; +Cc: Jim Porter, emacs-devel

> I think we should extend the functionality of closures by providing a
> way to access the bound variables in them.  Then we won't need to make
> Emacs Lisp more complicated with a new data type, because ordinary
> closures will do this job too.

That's exactly what fcr.el does.


        Stefan




^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-29 19:01         ` Stefan Monnier
@ 2021-12-30  2:54           ` LdBeth
  2021-12-30  4:28           ` Richard Stallman
  1 sibling, 0 replies; 38+ messages in thread
From: LdBeth @ 2021-12-30  2:54 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Jim Porter, Richard Stallman, emacs-devel

>>>>> In <jwvfsqb5j8j.fsf-monnier+emacs@gnu.org> 
>>>>>	Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> I think we should extend the functionality of closures by providing a
>> way to access the bound variables in them.  Then we won't need to make
>> Emacs Lisp more complicated with a new data type, because ordinary
>> closures will do this job too.

Stefan> That's exactly what fcr.el does.

That seems to be part of the functionality a Lisp Inspector provides:
access/editing various lisp objects.

-- 
LDB



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  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
  1 sibling, 1 reply; 38+ messages in thread
From: Richard Stallman @ 2021-12-30  4:28 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: jporterbugs, emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I think we should extend the functionality of closures by providing a
  > > way to access the bound variables in them.  Then we won't need to make
  > > Emacs Lisp more complicated with a new data type, because ordinary
  > > closures will do this job too.

  > That's exactly what fcr.el does.

I have not seen fcr.el -- would you please send me a copy?

However, if it does exactly what I described above, why do we need a
name other than "closures"?  Why do we need a new type of object?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-30  4:28           ` Richard Stallman
@ 2021-12-30  8:43             ` tomas
  2021-12-30 10:15               ` Tomas Hlavaty
  0 siblings, 1 reply; 38+ messages in thread
From: tomas @ 2021-12-30  8:43 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

On Wed, Dec 29, 2021 at 11:28:41PM -0500, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > > I think we should extend the functionality of closures by providing a
>   > > way to access the bound variables in them.  Then we won't need to make
>   > > Emacs Lisp more complicated with a new data type, because ordinary
>   > > closures will do this job too.
> 
>   > That's exactly what fcr.el does.
> 
> I have not seen fcr.el -- would you please send me a copy?
> 
> However, if it does exactly what I described above, why do we need a
> name other than "closures"?  Why do we need a new type of object?

Possibly because it diverges somewhat from the canonical meaning of
"closure" -- it might confuse people.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-30  8:43             ` tomas
@ 2021-12-30 10:15               ` Tomas Hlavaty
  2021-12-30 14:00                 ` Stefan Monnier
  0 siblings, 1 reply; 38+ messages in thread
From: Tomas Hlavaty @ 2021-12-30 10:15 UTC (permalink / raw)
  To: tomas, emacs-devel

On Thu 30 Dec 2021 at 09:43, <tomas@tuxteam.de> wrote:
> Possibly because it diverges somewhat from the canonical meaning of
> "closure" -- it might confuse people.

I don't think so.  Lisps usually expose a way to see the closed over
variables, so in reality, there is no such thing as "closures that don't
permit access".

You can do that in Emacs right now (maybe not portably across different
compiler backends):

ELISP> (defun foo (a b) (lambda (c) (+ a b c)))
foo
ELISP> (foo 3 5)
(closure
 ((b . 5)
  (a . 3)
  t)
 (c)
 (+ a b c))

ELISP> (defun faz (a b) (lambda (c) (error "a=%d b=%d" a b)))
faz
ELISP> (setq baz (faz 3 5))
(closure
 ((b . 5)
  (a . 3)
  t)
 (c)
 (error "a=%d b=%d" a b))
ELISP> (funcall baz 13)
*** Eval error ***  a=3 b=5
ELISP> (setq debug-on-error t)
t
ELISP> (funcall baz 13)
Debugger entered--Lisp error: (error "a=3 b=5")
  signal(error ("a=3 b=5"))
  error("a=%d b=%d" 3 5)
  (closure ((b . 5) (a . 3) t) (c) (error "a=%d b=%d" a b))(13)
  funcall((closure ((b . 5) (a . 3) t) (c) (error "a=%d b=%d" a b)) 13)
  eval((funcall baz 13) t)
  ielm-eval-input(#("(funcall baz 13)" 0 16 (fontified t)) nil)
  ielm-send-input(nil)
  ielm-return()
  funcall-interactively(ielm-return)
  call-interactively(ielm-return nil nil)
  command-execute(ielm-return)

ELISP> (car baz)
closure
ELISP> (cdr (assoc 'a (cadr baz)))
3 (#o3, #x3, ?\C-c)

ELISP> (rplacd (assoc 'a (cadr baz)) 42)
42 (#o52, #x2a, ?*)
ELISP> baz
(closure
 ((b . 5)
  (a . 42)
  t)
 (c)
 (error "a=%d b=%d" a b))



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-28 17:28         ` Stefan Monnier
@ 2021-12-30 10:35           ` Andreas Schwab
  0 siblings, 0 replies; 38+ messages in thread
From: Andreas Schwab @ 2021-12-30 10:35 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Po Lu, Richard Stallman, emacs-devel

On Dez 28 2021, Stefan Monnier wrote:

> Andreas Schwab [2021-12-28 12:24:32] wrote:
>> On Dez 28 2021, Po Lu wrote:
>>> Isn't the whole point of this feature "they're like closures but you can
>>> introspect the environment?"
>> If that's the only point, why can't we add that introspection facility
>> to closures?
>
> That's what it does ;-)

Why do you need a new name, then?

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  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
  0 siblings, 2 replies; 38+ messages in thread
From: Stefan Monnier @ 2021-12-30 14:00 UTC (permalink / raw)
  To: Tomas Hlavaty; +Cc: tomas, emacs-devel

> You can do that in Emacs right now (maybe not portably across different
> compiler backends):

It's not just "not portably": for compiled code, closures do not carry
the name of their captures variables.


        Stefan




^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-30 14:00                 ` Stefan Monnier
@ 2021-12-30 18:46                   ` Tomas Hlavaty
  2021-12-31  4:26                   ` Richard Stallman
  1 sibling, 0 replies; 38+ messages in thread
From: Tomas Hlavaty @ 2021-12-30 18:46 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: tomas, emacs-devel

On Thu 30 Dec 2021 at 09:00, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> for compiled code, closures do not carry the name of their captures
> variables.

This is the missing bit which should be added to emacs lisp.  And then
the emacs debugger should be able to display the captured variables and
values similar to what slime does for common lisp.



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-30 14:00                 ` Stefan Monnier
  2021-12-30 18:46                   ` Tomas Hlavaty
@ 2021-12-31  4:26                   ` Richard Stallman
  1 sibling, 0 replies; 38+ messages in thread
From: Richard Stallman @ 2021-12-31  4:26 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: tomas, tom, emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It's not just "not portably": for compiled code, closures do not carry
  > the name of their captures variables.

Now I understand why you're proposing a new data type.

I think it would be simpler overall to make the API for using
these maximally similar to the API for closures.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2021-12-29 16:33   ` Lars Ingebrigtsen
@ 2022-01-04 20:31     ` Stefan Monnier
  2022-01-11  3:25       ` Filipp Gunbin
  0 siblings, 1 reply; 38+ messages in thread
From: Stefan Monnier @ 2022-01-04 20:31 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Bob Rogers, emacs-devel

Lars Ingebrigtsen [2021-12-29 17:33:54] wrote:
> Bob Rogers <rogers-emacs@rgrjr.homedns.org> writes:
>> Without looking at the code, this sounds more like a closure to me.
>> 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.  ;-}
> "Open closure" gets my vote.  🙃

The branch is now named `scratch/oclosure`


        Stefan




^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2022-01-04 20:31     ` Stefan Monnier
@ 2022-01-11  3:25       ` Filipp Gunbin
  2022-01-11  3:44         ` Stefan Monnier
  0 siblings, 1 reply; 38+ messages in thread
From: Filipp Gunbin @ 2022-01-11  3:25 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

I have an association with letter: body / message (closure in our case)
is inside the envelope, inaccessible and hidden from eyes, while header
/ a set of name-value pairs (record in our case) is written on the
envelope itself, and visible.

So: function letter, or funlet ?

I haven't seen the code, just read this thread :-)

Filipp



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2022-01-11  3:25       ` Filipp Gunbin
@ 2022-01-11  3:44         ` Stefan Monnier
  2022-01-12  4:56           ` Richard Stallman
  0 siblings, 1 reply; 38+ messages in thread
From: Stefan Monnier @ 2022-01-11  3:44 UTC (permalink / raw)
  To: Filipp Gunbin; +Cc: emacs-devel

> I have an association with letter: body / message (closure in our case)
> is inside the envelope, inaccessible and hidden from eyes, while header
> / a set of name-value pairs (record in our case) is written on the
> envelope itself, and visible.
> So: function letter, or funlet ?

No bad.  But I already renamed FCR to O(pen)Closure.


        Stefan




^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2022-01-11  3:44         ` Stefan Monnier
@ 2022-01-12  4:56           ` Richard Stallman
  2022-01-12 15:10             ` Stefan Monnier
  0 siblings, 1 reply; 38+ messages in thread
From: Richard Stallman @ 2022-01-12  4:56 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: fgunbin, emacs-devel

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > No bad.  But I already renamed FCR to O(pen)Closure.

What is the API for using open closures?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Naming FCRs
  2022-01-12  4:56           ` Richard Stallman
@ 2022-01-12 15:10             ` Stefan Monnier
  0 siblings, 0 replies; 38+ messages in thread
From: Stefan Monnier @ 2022-01-12 15:10 UTC (permalink / raw)
  To: Richard Stallman; +Cc: fgunbin, emacs-devel

Richard Stallman [2022-01-11 23:56:05] wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>   > No bad.  But I already renamed FCR to O(pen)Closure.
> What is the API for using open closures?

`oclosure-define` to define new OClosure types (similar to
`cl-defstruct`), and `oclosure-lambda` to actually create new
OClosure objects (basically a `lambda` with one more argument
specifying the type and of the object and the value of its fields).


        Stefan




^ permalink raw reply	[flat|nested] 38+ messages in thread

end of thread, other threads:[~2022-01-12 15:10 UTC | newest]

Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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).