Naming FCRs

Naming FCRs

[Stefan Monnier]

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

Re: Naming FCRs

[Dmitry Gutov]

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.

Naming FCRs

[Bob Rogers]

   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/

Re: Naming FCRs

[Po Lu]

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"?

Re: Naming FCRs

[Qiantan Hong]

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

Re: Naming FCRs

[Stefan Monnier]

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

Re: Naming FCRs

[Richard Stallman]

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

Re: Naming FCRs

[Jim Porter]

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

Re: Naming FCRs

[LdBeth]

> 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

Re: Naming FCRs

[tomas]

[-- 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 --]

Re: Naming FCRs

[Stefan Monnier]

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

Re: Naming FCRs

[Stefan Monnier]

> 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

Re: Naming FCRs

[Dmitry Gutov]

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.

Re: Naming FCRs

[Richard Stallman]

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

Re: Naming FCRs

[Po Lu]

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?"

Re: Naming FCRs

[Andreas Schwab]

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

Re: Naming FCRs

[xenodasein--- via Emacs development discussions.]

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

Re: Naming FCRs

[Stefan Monnier]

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

Re: Naming FCRs

[Jim Porter]

(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?

Re: Naming FCRs

[Phil Sainty]

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.

Re: Naming FCRs

[Phil Sainty]

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.

Re: Naming FCRs

[Richard Stallman]

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

Re: Naming FCRs

[Lars Ingebrigtsen]

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

RE: [External] : Re: Naming FCRs

[Drew Adams]

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

Re: Naming FCRs

[Stefan Monnier]

> 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

Re: Naming FCRs

[LdBeth]

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

Re: Naming FCRs

[Richard Stallman]

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

Re: Naming FCRs

[tomas]

[-- 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 --]

Re: Naming FCRs

[Tomas Hlavaty]

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

Re: Naming FCRs

[Andreas Schwab]

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

Re: Naming FCRs

[Stefan Monnier]

> 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

Re: Naming FCRs

[Tomas Hlavaty]

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.

Re: Naming FCRs

[Richard Stallman]

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

Re: Naming FCRs

[Stefan Monnier]

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

Re: Naming FCRs

[Filipp Gunbin]

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

Re: Naming FCRs

[Stefan Monnier]

> 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

Re: Naming FCRs

[Richard Stallman]

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

Re: Naming FCRs

[Stefan Monnier]

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