the acronym (?) REPL must be new in Lisp (and Scheme)

i'm sure i never saw it (used or mentioned) 25 years ago.

On Wed, 10 Jul 2024 19:11:17 -0700, HenHanna wrote:

> the acronym (?) REPL must be new in Lisp (and Scheme)
>
> i'm sure i never saw it (used or mentioned) 25 years ago.

There are many new terms coined for old concepts. Like “capture” for
“lexical binding”, or “dependency injection” for “callback”.

HenHanna <HenHanna@devnull.tb> writes:

> the acronym (?) REPL must be new in Lisp (and Scheme)
>
> i'm sure i never saw it (used or mentioned) 25 years ago.

I remember REPL back until the early 80s. Wikipedia does not contradict
and adds a bit more:

<https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop>

History

In 1964, the expression READ-EVAL-PRINT cycle is used by L. Peter
Deutsch and Edmund Berkeley for an implementation of Lisp on the
PDP-1.

Since at least the 1980s, the abbreviations REP Loop and REPL are
attested in the context of Scheme.

--
( $#"&?"#=-#@!!! )
/

_ _ _ _ _ _ _ _ _ _ _ _ |\ _ _ _ _ _ _ _ _ _ \o/ _ _ _ _ _ _ _ _ _ _ _ _

On 7/10/2024 10:26 PM, yeti wrote:
> HenHanna <HenHanna@devnull.tb> writes:
>
>> the acronym (?) REPL must be new in Lisp (and Scheme)
>>
>> i'm sure i never saw it (used or mentioned) 25 years ago.
>

> I remember REPL back until the early 80s. Wikipedia does not contradict
> and adds a bit more:
>
> <https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop>
>
> History
>
> In 1964, the expression READ-EVAL-PRINT cycle is used by L. Peter
> Deutsch and Edmund Berkeley for an implementation of Lisp on the
> PDP-1.
>
> Since at least the 1980s, the abbreviations REP Loop and REPL are
> attested in the context of Scheme.
>

afaicr in the 1980's everyone spelled it out as

Read-Eval-Print Loop or Cycle.

(i think) Guy Steele's AI Memos sometimes used [R-E-P Loop]
but never REPL

On 7/10/2024 7:26 PM, Lawrence D'Oliveiro wrote:
> On Wed, 10 Jul 2024 19:11:17 -0700, HenHanna wrote:
>
>> the acronym (?) REPL must be new in Lisp (and Scheme)
>>
>> i'm sure i never saw it (used or mentioned) 25 years ago.
>

> There are many new terms coined for old concepts. Like “capture” for
> “lexical binding”, or “dependency injection” for “callback”.

thanks. List "comprehension" was new to me.

maybe there're pronunciation changes....

in the old days, CONS was pronounced [kahnzzz]

i always preferred [cohns]

--- after all, it's short for "Construct"

HenHanna <HenHanna@devnull.tb> writes:

> the acronym (?) REPL must be new in Lisp (and Scheme)
> i'm sure i never saw it (used or mentioned) 25 years ago.

https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop#History

"In 1964, the expression READ-EVAL-PRINT cycle is used by L. Peter
Deutsch and Edmund Berkeley for an implementation of Lisp on the
PDP-1.[3] Since at least the 1980s, the abbreviations REP Loop and REPL
are attested in the context of Scheme.[4][5] "

On 2024-07-11, Paul Rubin <no.email@nospam.invalid> wrote:
> HenHanna <HenHanna@devnull.tb> writes:
>
>> the acronym (?) REPL must be new in Lisp (and Scheme)
>> i'm sure i never saw it (used or mentioned) 25 years ago.
>
> https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop#History
>
> "In 1964, the expression READ-EVAL-PRINT cycle is used by L. Peter
> Deutsch and Edmund Berkeley for an implementation of Lisp on the
> PDP-1.[3] Since at least the 1980s, the abbreviations REP Loop and REPL
> are attested in the context of Scheme.[4][5] "

What's your one REP(L) max, dude?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Wed, 10 Jul 2024 19:11:17 -0700, HenHanna wrote:
>
>> the acronym (?) REPL must be new in Lisp (and Scheme)
>>
>> i'm sure i never saw it (used or mentioned) 25 years ago.
>
> There are many new terms coined for old concepts. Like “capture” for
> “lexical binding”, or “dependency injection” for “callback”.
>

I can more or less see how callbacks can be used as a kind of dependency
injection, but those are separate concepts.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Wed, 10 Jul 2024 19:11:17 -0700, HenHanna wrote:
>
>> the acronym (?) REPL must be new in Lisp (and Scheme)
>>
>> i'm sure i never saw it (used or mentioned) 25 years ago.
>
> There are many new terms coined for old concepts. Like “capture” for
> “lexical binding”, or “dependency injection” for “callback”.

Can you elaborate on "dependency injection" for "callback"? It would be
nice if a small example be presented in a popular language such as Lisp
or Python.

Looking the term up, it seems sufficiently different from "callback".

(This is a genuine request for information. I never understood why we
need the term "dependency injection".

Julieta Shem <jshem@yaxenu.org> wrote:
>
> I never understood why we
> need the term "dependency injection".
>

Would you just spell out 'determine/decide/provide concrete implementations
of dependencies dynamically' every time?

On Thu, 11 Jul 2024 12:57:12 -0000 (UTC), Antonio Marques wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Wed, 10 Jul 2024 19:11:17 -0700, HenHanna wrote:
>>
>>> the acronym (?) REPL must be new in Lisp (and Scheme)
>>>
>>> i'm sure i never saw it (used or mentioned) 25 years ago.
>>
>> There are many new terms coined for old concepts. Like “capture” for
>> “lexical binding”, or “dependency injection” for “callback”.
>>
> I can more or less see how callbacks can be used as a kind of dependency
> injection, but those are separate concepts.

“Dependency injection” is just packaging up a bunch of callbacks as
methods in a class.

On 2024-07-11, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Wed, 10 Jul 2024 19:11:17 -0700, HenHanna wrote:
>
>> the acronym (?) REPL must be new in Lisp (and Scheme)
>>
>> i'm sure i never saw it (used or mentioned) 25 years ago.
>
> There are many new terms coined for old concepts. Like “capture” for
> “lexical binding”, or “dependency injection” for “callback”.

Lexical binding does not imply closure/capture.

C has lexical scoping without capture: the bindings are destroyed
when their associated scope terminates.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Wed, 10 Jul 2024 19:11:17 -0700, HenHanna <HenHanna@devnull.tb>
wrote:

>
>the acronym (?) REPL must be new in Lisp (and Scheme)
>
>
>i'm sure i never saw it (used or mentioned) 25 years ago.

I don't know when exactly it was coined, but "REPL" meaning
"read-evaluate-print loop" goes back at least 30 years to the late
80's.

I first heard it in connection to Lisp, but it was clear even then
that Scheme was using the same lexicon.

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Thu, 11 Jul 2024 12:57:12 -0000 (UTC), Antonio Marques wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> On Wed, 10 Jul 2024 19:11:17 -0700, HenHanna wrote:
>>>
>>>> the acronym (?) REPL must be new in Lisp (and Scheme)
>>>>
>>>> i'm sure i never saw it (used or mentioned) 25 years ago.
>>>
>>> There are many new terms coined for old concepts. Like “capture” for
>>> “lexical binding”, or “dependency injection” for “callback”.
>>>
>> I can more or less see how callbacks can be used as a kind of dependency
>> injection, but those are separate concepts.
>
> “Dependency injection” is just packaging up a bunch of callbacks as
> methods in a class.
>

That's like saying Formula One is just putting cigarette stickers in your
boat.

Follow-up to comp.lang.lisp. Even though it doesn't even belong to
comp.lang.lisp, let's at least free other groups from this topic. Or
provide me with better judgement.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Thu, 11 Jul 2024 12:57:12 -0000 (UTC), Antonio Marques wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> On Wed, 10 Jul 2024 19:11:17 -0700, HenHanna wrote:
>>>
>>>> the acronym (?) REPL must be new in Lisp (and Scheme)
>>>>
>>>> i'm sure i never saw it (used or mentioned) 25 years ago.
>>>
>>> There are many new terms coined for old concepts. Like “capture” for
>>> “lexical binding”, or “dependency injection” for “callback”.
>>>
>> I can more or less see how callbacks can be used as a kind of dependency
>> injection, but those are separate concepts.
>
> “Dependency injection” is just packaging up a bunch of callbacks as
> methods in a class.

Why would you say ``packaging up''? Can we look at Wikipedia? (I'd
appreciate a good reference. I don't know exactly where to look.)

--8<-------------------------------------------------------->8---
[...] dependency injection is a programming technique in which an
object or function receives other objects or functions that it
requires, as opposed to creating them internally. Dependency injection
aims to separate the concerns of constructing objects and using them,
leading to loosely coupled programs.[1][2][3] The pattern ensures that
an object or function that wants to use a given service should not
have to know how to construct those services. Instead, the receiving
'client' (object or function) is provided with its dependencies by
external code (an 'injector'), which it is not aware of. --Wikipedia
--8<-------------------------------------------------------->8---

So I see why you're saying ``callback'' because the object or function
will call your procedures to get what it needs (instead of creating them
internally). But why would say ``packaging up''? (Couldn't I
``inject'' the ``dependencies'' by passing them all as arguments.)

I suppose ``packaging up'' would be appropriate if we pass in to a
procedure an object containing all the callbacks that you say.

Anyway, my interpretation of the Wikipedia article is merely
abstraction. Nothing but abstraction. I don't see why we need to call
it ``injection'' or even ``dependency'', even though the choice of words
isn't absurd.

(*) The source

Dependency injection
https://en.wikipedia.org/wiki/Dependency_injection

Julieta Shem <jshem@yaxenu.org> wrote:
> Follow-up to comp.lang.lisp. Even though it doesn't even belong to
> comp.lang.lisp, let's at least free other groups from this topic. Or
> provide me with better judgement.
>
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Thu, 11 Jul 2024 12:57:12 -0000 (UTC), Antonio Marques wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>>> On Wed, 10 Jul 2024 19:11:17 -0700, HenHanna wrote:
>>>>
>>>>> the acronym (?) REPL must be new in Lisp (and Scheme)
>>>>>
>>>>> i'm sure i never saw it (used or mentioned) 25 years ago.
>>>>
>>>> There are many new terms coined for old concepts. Like “capture” for
>>>> “lexical binding”, or “dependency injection” for “callback”.
>>>>
>>> I can more or less see how callbacks can be used as a kind of dependency
>>> injection, but those are separate concepts.
>>
>> “Dependency injection” is just packaging up a bunch of callbacks as
>> methods in a class.
>
> Why would you say ``packaging up''? Can we look at Wikipedia? (I'd
> appreciate a good reference. I don't know exactly where to look.)
>
> --8<-------------------------------------------------------->8---
> [...] dependency injection is a programming technique in which an
> object or function receives other objects or functions that it
> requires, as opposed to creating them internally. Dependency injection
> aims to separate the concerns of constructing objects and using them,
> leading to loosely coupled programs.[1][2][3] The pattern ensures that
> an object or function that wants to use a given service should not
> have to know how to construct those services. Instead, the receiving
> 'client' (object or function) is provided with its dependencies by
> external code (an 'injector'), which it is not aware of. --Wikipedia
> --8<-------------------------------------------------------->8---
>
> So I see why you're saying ``callback'' because the object or function
> will call your procedures to get what it needs (instead of creating them
> internally). But why would say ``packaging up''?

(You shouldn't be trying to make sense of information provided by someone
who admits to not understanding it.)

> (Couldn't I
> ``inject'' the ``dependencies'' by passing them all as arguments.)

That's one way to do it. In languages that rely on 'objects' it's
fashionable to declare a field for each dependency, with an annotation that
says it's a dependency, and some framework will provide the values at run
time (there will be some framework-specific way to instantiate the
dependencies).

>
> I suppose ``packaging up'' would be appropriate if we pass in to a
> procedure an object containing all the callbacks that you say.
>
> Anyway, my interpretation of the Wikipedia article is merely
> abstraction. Nothing but abstraction. I don't see why we need to call
> it ``injection'' or even ``dependency'', even though the choice of words
> isn't absurd.

Again, abstraction is just a requirement. There's few things in software
that don't imply some form of abstraction, so that word doesn't get us very
far.

Dependency injection is all about the injection: someone provides your
dependencies for you, and what concrete implementations of those is
something that can and will vary.

> (*) The source
>
> Dependency injection
> https://en.wikipedia.org/wiki/Dependency_injection
>

On Fri, 12 Jul 2024 18:12:48 -0300, Julieta Shem wrote:

> But why would say ``packaging up''? (Couldn't I
> ``inject'' the ``dependencies'' by passing them all as arguments.)

Precisely my point. You can indeed.

Ar an dara lá déag de mí Iúil, scríobh Kaz Kylheku:

> On 2024-07-11, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> > On Wed, 10 Jul 2024 19:11:17 -0700, HenHanna wrote:
> >
> >> the acronym (?) REPL must be new in Lisp (and Scheme)
> >>
> >> i'm sure i never saw it (used or mentioned) 25 years ago.
> >
> > There are many new terms coined for old concepts. Like “capture” for
> > “lexical binding”, or “dependency injection” for “callback”.
>
> Lexical binding does not imply closure/capture.

I’ve never seen “capture” used as a general term for closures or for lexical
scope in this way; are we sure it’s what was meant?

> C has lexical scoping without capture: the bindings are destroyed
> when their associated scope terminates.

--
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after fourteen pints of stout’
(C. Moore)

Antonio Marques <no_email@invalid.invalid> writes:

> Julieta Shem <jshem@yaxenu.org> wrote:

[...]

>> (Couldn't I
>> ``inject'' the ``dependencies'' by passing them all as arguments[?])
>
> That's one way to do it. In languages that rely on 'objects' it's
> fashionable to declare a field for each dependency, with an annotation that
> says it's a dependency, and some framework will provide the values at run
> time (there will be some framework-specific way to instantiate the
> dependencies).

Got it.

>> I suppose ``packaging up'' would be appropriate if we pass in to a
>> procedure an object containing all the callbacks that you say.
>>
>> Anyway, my interpretation of the Wikipedia article is merely
>> abstraction. Nothing but abstraction. I don't see why we need to call
>> it ``injection'' or even ``dependency'', even though the choice of words
>> isn't absurd.
>
> Again, abstraction is just a requirement. There's few things in software
> that don't imply some form of abstraction, so that word doesn't get us very
> far.

Thanks. That makes perfect sense.

> Dependency injection is all about the injection: someone provides your
> dependencies for you, and what concrete implementations of those is
> something that can and will vary.

It's very clear now. Thank you so much.

On 2024-07-13, Julieta Shem <jshem@yaxenu.org> wrote:
>> Dependency injection is all about the injection: someone provides your
>> dependencies for you, and what concrete implementations of those is
>> something that can and will vary.
>
> It's very clear now. Thank you so much.

Therfore, a funtion that is used with different callbacks all the time,
like mapcar in Lisp or qsort in C, is not dependency injection.
Invocations of these functions forget about the callback when they are done.

An API that offers multiple handle instances to the clients, and
the handles can bind callbacks for notification, also doesn't look
like dependency inversion.

There is a a sense that the indirection is used to set up a single
instance of some needed resources which could be, in principle,
set up without indirection.

In the firmware application that I work on, I was asked to resolve a
circular reference between two separate components that were calling
each other's functions. The solution was to register indirect functions
for one calling direction. The registered functions are set once
at startup and do not vary.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Sat, 13 Jul 2024 08:24:27 +0100, Aidan Kehoe <kehoea@parhasard.net>
wrote:

>
> Ar an dara lá déag de mí Iúil, scríobh Kaz Kylheku:
>
> > On 2024-07-11, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> > > On Wed, 10 Jul 2024 19:11:17 -0700, HenHanna wrote:
> > >
> > >> the acronym (?) REPL must be new in Lisp (and Scheme)
> > >>
> > >> i'm sure i never saw it (used or mentioned) 25 years ago.
> > >
> > > There are many new terms coined for old concepts. Like “capture” for
> > > “lexical binding”, or “dependency injection” for “callback”.
> >
> > Lexical binding does not imply closure/capture.
>
>I’ve never seen “capture” used as a general term for closures or for lexical
>scope in this way; are we sure it’s what was meant?

"Capture" is exactly what was meant.

When a closure references variables from external scopes - that is
things are that are neither arguments nor locals - it is said to
"capture" those variables.

Lisp and Scheme create a copy of the captured variable in the closure
and compile the code to reference the closure's copy rather than the
original [which may no longer exist or may not be in scope when the
closure code finally is executed].

> > C has lexical scoping without capture: the bindings are destroyed
> > when their associated scope terminates.

And C++ now has closures with control over capture. If you choose not
to capture, external variables that are referenced must be in scope
(at their right locations) if and when the closure code is executed.

Ar an ceathrú lá déag de mí Iúil, scríobh George Neuner:

> On Sat, 13 Jul 2024 08:24:27 +0100, Aidan Kehoe <kehoea@parhasard.net>
> wrote:
>
> >
> > Ar an dara lá déag de mí Iúil, scríobh Kaz Kylheku:
> >
> > > On 2024-07-11, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> > > > On Wed, 10 Jul 2024 19:11:17 -0700, HenHanna wrote:
> > > >
> > > >> the acronym (?) REPL must be new in Lisp (and Scheme)
> > > >>
> > > >> i'm sure i never saw it (used or mentioned) 25 years ago.
> > > >
> > > > There are many new terms coined for old concepts. Like “capture” for
> > > > “lexical binding”, or “dependency injection” for “callback”.
> > >
> > > Lexical binding does not imply closure/capture.
> >
> >I’ve never seen “capture” used as a general term for closures or for lexical
> >scope in this way; are we sure it’s what was meant?
>
> "Capture" is exactly what was meant.
>
> When a closure references variables from external scopes - that is
> things are that are neither arguments nor locals - it is said to
> "capture" those variables.

Or to “close around” those variables.

Your reference to C++ clarified things, I had and have no interest in using
that language and so I had not known that “capture” is used for the Lisp
“closure” in recent versions of C++ that support it.

> Lisp and Scheme create a copy of the captured variable in the closure
> and compile the code to reference the closure's copy rather than the
> original [which may no longer exist or may not be in scope when the
> closure code finally is executed].
>
> > > C has lexical scoping without capture: the bindings are destroyed
> > > when their associated scope terminates.
>
> And C++ now has closures with control over capture. If you choose not
> to capture, external variables that are referenced must be in scope
> (at their right locations) if and when the closure code is executed.
>

--
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after fourteen pints of stout’
(C. Moore)